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Executive Summary 


This deliverable is the first document of Work Package 5 (WP5) of SDN-microSENSE. WP5 focuses on 
cybersecurity protection in the EPES domain, including components for the monitoring of EPES 
infrastructures, detection of cyber incidents associated to application protocols commonly used EPES 
networks (T5.1), the development of components for detecting cyber incidents linked to these 
protocols (T5.2, T5.3, T5.4), and threat intelligence sharing capabilities within EPES (T5.4). 


The content of this deliverable is focused on the description of the incident detection component 
included as part of the XL-EDPS module of the SDN-microSENSE architecture, which is based on the 
ATOS XL-SIEM. Within the XL-EDPS module, the ATOS XL-SIEM acts as a broker that links detectors 
deployed in the EPES infrastructure to monitor (IPS developed in T5.1, machine learning-based incident 
detectors developed in T5.2, access control monitoring developed in T5.4 and honeypots used in WP3), 
and the consumers of the XL-EDPS output, which is used by several components of the SDN- 
microSENSE architecture, such as S-RAF (developed in WP2), Honeypot Manager (developed in WP3) 
and threat intelligence sharing component like the ARIEC (developed in T5.4). 


More specifically, the XL-SIEM has been enhanced to support the processing of events coming from 
detectors developed in T5.2, T5.2 and T5.4, supporting events associated to protocols commonly used 
by EPES, such as Modbus, DNP3, IEC 60870-5-104, IEC61850 and IEEE C37.118. These protocols and 
the detectors capable of detecting incidents associated to these protocols, are introduced in this a 
document, with the intention to provide with a complete overview of the new application context 
introduced in the XL-SIEM. Those protocols and the corresponding details on detectors are thoroughly 
described in T5.2 and T5.3. Introducing support for these protocols to the XL-SIEM entailed integration 
efforts on the event processing side, which required the development of connectors capable of 
interpreting the new set of logs received from the new set of detectors developed in SDN-microSENSE. 
The correct interpretation of those logs and the information contained by them were key to add new 
intelligence capabilities to the XL-SIEM by means of new correlation rules that correctly interpret 
anomalous patterns associated to the logs received. 


On the other side, attached to the XL-SIEM and as part of the XL-EPDS, a set of interfaces, based on 
messages queues, has been integrated to export both events received by the XL-SIEM and the security 
alerts produced by it. This information is consumed by several components of the SDN-microSENSE 
architecture, which triggers additional activities such as the automatic deployment of honeypots when 
zero day attacks are detected (WP3), the sharing of threat information through the ARIEC (T5.4) or the 
risk evaluation of incidents carried out by the S-RAF component (WP4). 
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1 Introduction 

This document details the technical details of the developments carried out in incident detection 
component that is part of the XL-EPDS module in the SDN-microSENSE architecture. The main purpose 
of this component, which is based on the ATOS XL-SIEM, is to act as broker between the security 
detectors that are monitoring the EPES infrastructure and the components that consume information 
about security alerts detected by the incident detector. To this end, the XL-SIEM has been adapted to 
process events coming from detectors related to EPES specific protocols, including also the intelligence 
to interpret such information, correlate those events to produce the corresponding security alerts. A 
set of connectors have also been developed at the input side of the XL-SIEM, to interpret logs coming 
from new detectors, and output connectors to push verdicts about incidents detected that are used 
by several components of the SDN-microSENSE platform. 


This document is structured as follows: 


e Section 2 provides an overview of the XL-EPDS module of the SDN-microSENSE architecture 
and position it in the context of the rest of components of the platform. 

e Section 3 provides with details related to the incident detection component used in the XL- 
EPDS module, together with deployment considerations in the context of SDN-microSENSE. 

e Section 4 introduces the monitoring and detectors used in the XL-EPDS, including a high-level 
overview of the protocols and approaches to monitor them. 

e Section 5 provides details about the inputs of the XL-EPDS component and the interfaces 
deployed to retrieve logs from detectors. 

e Section 6 provides details about the output of the XL-EPDS component and the interfaces 
deployed to push security alerts to alerts consumers. 

e Section 7 details the testbed deployed to check connectivity between XL-EPDS components 
and summarizes the unit testing carried out. 

e Section 8 concludes the document and summarises the main innovations carried out in this 
task. 


1.1 Relation to other Tasks and Deliverables 
This document is related to the following deliverables (Figure 1): 


e D2.2 [SDN22], where the requirements of the SDN-microSENSE platform are elicited 

e D2.3 [SDN23], where the SDN-microSENSE architecture is described 

e D2.4 [SDN24], from where it is taken the validation methodology 

e D3.3 [SDN33], that describes the honeypots that will interact with the XL-EPDS 

e D5.2 [SDN52], that describes the protocols, attacks and detectors and details the SDN based IDS 
e D5.3 [SDN53], that describes the machine learning based detectors 

e D5.4 [SDN54], that describes the privacy framework that interconnects to the XL-EPDS 

e D5.5 [SDN55], that describes the ARIEC which uses the output of the XL-EPDS 
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Figure 1. Links between D5.1 and the rest of deliverables and WPs 


1.2 Requirements analysis 
The following requirements elicited from D2.2 [SDN22] are covered by the components described in 
this document. 


Functional Requirements General Requirements 

FR-GR-03, related to the generation of alarms related to incidents. 

FR-GR-05, related to the ability to provide network flow metrics from network data 

FR-GR-09, related to the availability of interfaces for integrating external components such as 
detectors. 

FR-GR-10, related to the storage of events and incident information in a persistent database 
FR-GR-11, related to the availability of GUIs to visualize incident information 

FR-GR-12, related to the collection of security events 

Functional Requirements User Requirements 

FR-UR-03 to 14, which describe requirements related to the detection of different types of cyber 
attacks 

FR-UR-17, which describes que remote notification of incidents detected 

Functional Requirements Use Case Requirements 

FR-UC1-01 to 03, which cover cyber-attacks to SCADAs logical interface under the Use Case 1 
FR-UC1-04 to 07, which cover cyber-attacks to the Station Bus network under the Use Case 1 
FR-UC1-08 to 11, which cover cyber-attacks against the process control bus 

FR-UC3-01, which cover the defence against coordinated attacks scenarios in the Islanding Use Case 
3. 

Non-Functional requirements 

All non-functional requirements refined in Table 12 of D2.2 are covered by this deliverable 
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2 XL-EPDS overview 


The XL-EPDS subsystem of the SDN-microSENSE platform carries out the tasks related to infrastructure 
monitoring, incident detection and incident reporting. As shown in Figure 2, the XL-EPDS is located at 
the Application Plane. It directly interacts with the data and infrastructure plane, obtaining monitoring 
data (logs, network traffic, etc) from the components and network of this plane. It also interacts with 
the controller plane to obtain data from SDN controllers and infer incidents and anomalies based on 
the data obtained from this plane. Other elements of the Application Plane (i.e., S-RAF), use 
information from the XL-EPDS (such as security alerts). Further details of the XL-EPDS within the SDN- 
microSENSE architecture can be checked in Deliverable D2.3. 


APPLICATION PLANE 


Lone 1)0L.L.1LL)d 
i CONTROLLER PLANE 
E E 


DATA/INFRASTRUCTURE PLANE 


Figure 2. The XL-EPDS within the high level SDN-microSENSE architecture 


The internals of the XL-EPDS consists on several components that cover the full cycle of the security 
management: monitoring, analysis, reporting, mitigating. The details of the XL-EPDS components, and 
their interrelation, are depicted in Figure 3 in the context of WP5 components and WP5 tasks. 
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Figure 3. XL-EPDS global architecture 


Four main parts can be identified in such figure: 
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e EPES Infrastructure, which corresponds to the Data/Infrastructure plane and Controller plane 
of the SDN-microSENSE architecture. Control centres, substations and SDN controllers are part 
of this group. 

e Detectors, which correspond to all those components that provide with logs, evidences, and 
information relevant to be used to infer security alerts. We include here IDPS detectors and 
SDN IDPS (part of T5.2), machine learning based detectors (part of T5.3), honeypots (part of 
T3.3), and components for reporting about access control and data requests (part of T5.4). 

e The reasoning engine of the XL-EPDS are the XL-SIEM components (part of T5.1) which are 
composed of XL-SIEM agents and the XL-SIEM engine. 

e Consumers of security alerts, including here: 

o Risk assessment (by the OLISTIC component at the S-RAF), part of T3.1 

o Intelligent sharing components, such as the ATOS CIS and the ARIEC, part of T5.5 

o Visualization components, such as the Discovery tool developed in T5.3 

o Honeypot manager for the dynamic deployment of honeypots based on incidents 
detected and being developed in T3.3. 


The following sections describes the details of the T5.1 components. 
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3 Incident detection based on the XL-SIEM in SDN-microSENSE 


The core of the XL-EPDS subsystem is the ATOS XL-SIEM (highlighted in Figure 4), which interfaces with 
detectors, which provide input data, and three main parts of the SDN-microSENSE as consumers of the 
XL-SIEM output: OLISTIC component, ARIEC and the Discovery System. 


MP] Nightwatch 
logs events) 
bag lormalized 
XL-SIEM events PEST Alar: 
Raw logs Agents 


g Engine 


Figure 4. T5.1 components within WP5 architecture 


The XL-SIEM is an event-based incident detector that can be attached to a myriad of different sources 
of information, basically, any component capable of providing logs, events or any type of data relevant 
for detecting cyber incidents. 


Compared with other SIEM solutions, the XL-SIEM is particularly strong in flexibility and performance 
related aspects. In general, SIEM solutions are heavy platforms, with high computational 
requirements, also requiring dedicating support for deployment and maintenance. On the contrary, as 
it will be detailed in next subsections, the Atos XL-SIEM is built upon a fully modular approach, based 
on an Apache Storm topology deployed on docker containers, which allows to tailor the capabilities of 
the XL-SIEM to the specific needs of the infrastructure where it is operating. 


For these reasons, the XL-SIEM is suitable for its usage in very specific domains (from SMEs to Critical 
Infrastructures) allowing to be extended to new technologies or future threats. To this end, the Gartner 
report publishes every year a market study comparing commercial SIEMs from different vendors 
[Gartner2020]. Figure 5 represents the Magic Quadrant published in February 2020, which analyses 
the market positioning of different SIEM solutions: from leaders to visionaries or SIEMs focused in 
niches. Overlapped to the Gartner study it has been included the position of the XL-SIEM in orange, 
halfway between niche focused (because, as said, the XL-SIEM was developed to be tailored to 
different infrastructures, from difference sizes and criticality), and visionaries (because, it can is 
constantly extended with new capabilities and new application domains, such as the EPES domain in 
SDN-microSENSE). 
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Figure 5. Gartner magic quadrant for SIEMS (taken [Gartner2020]) positioning the XL-SIEM (in orange) 


To this end, for its adaptation to the SDN-microSENSE environment, it has been required an effort of 
adaptation to new communication protocols, which are typically not considered in the current SIEM 
solutions. The innovations carried out to be able to use the XL-SIEM within SDN-microSENSE are 
detailed in Section 8. Atos is the developer and owner of the XL-SIEM which has been used in T5.1 and 
is the umbrella that interconnects the rest of the components of WP5. 


The following subsection details the internals of the XL-SIEM. 


3.1 XL-SIEM Deployment Considerations 
The XL-SIEM is composed of two main parts: one or more agents and one correlation engine. 


XL-SIEM agents are light software components that are deployed in any part of the infrastructure. 
These agents will receive, from other components (sensors, detectors, or any other component 
deployed in any infrastructure) logs, events or any other information that can be used to infer an 
anomaly or a security incident. XL-SIEM agents aggregate, filter and normalize the logs received Figure 
6. 


© SDN-microSENSE consortium Page | 16 
Public document 


e SDN-u Sense 
D5.1 


Version 1.5 


XL-SIEM 


Normalized events 


WEIEN C> Security alerts 
engine 
XL-SIEM € Normalized events 


Figure 6. XL-SIEM overview 


The mechanisms used to provide inputs to the XL-SIEM agents and to provide normalized events as 
output will be described in Section 4.2.8. 


The other part of the XL-SIEM is the engine, which can be considered the core of the XL-SIEM. The 
internal representation of the XL-SIEM engine is represented in Figure 7. The XL-SIEM engine is based 
on two main technologies: Apache zookeeper and Apache Storm. The former is used to coordinate and 
control the execution of the rest of the components of the XL-SIEM engine. The latter is used to run 
the Storm topology that supports all the activities carried out by the XL-SIEM. As part of the Apache 
Storm used at the XL-SIEM engine there are three main subcomponents: workers are the actual 
elements that perform specific tasks, such as interacting with databases or applying correlation rules. 
Those workers are instantiated by supervisors, which can be deployed even at different machines and 
thus enabling a distributed deployment. This is one of the main advantages of using Apache Storm, 
because, depending on the requirements and resources available, it is possible to deploy supervisors 
distributed in different machines, instantiated or withdrawing supervisors dynamically as long as they 
are required. On top of these supervisors, there is an additional node, called Nimbus, which controls 
the tasks assigned to supervisors, controlling the deployment of supervisor nodes and the correct 
schedule and cooperation across them. 
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Figure 7. Internals of the XL-SIEM engine 


The XL-SIEM has evolved as part of the activities carried out in SDN-microSENSE. The main 
improvement leverages the adaptability to the characteristics of the infrastructure where it is 
deployed. While in the past the XL-SIEM was built on a monolithic distribution to be instantiated on 
top of a Linux based operative system running on a dedicated machine, the latest improvements use 
Docker based containers to separate the different subcomponents of the XL-SIEM. This provides 
several advantages: 


e Optimization of resources required to run the XL-SIEM Engine. The resources required to 
execute the XL-SIEM Engine has dropped significantly (up to half in terms of CPU and RAM) 
with the migration to Docker containers. 

e Easy distributed deployment, with the possibility to deploy Docker containers for Nimbus, 
Supervisor and Zookeeper in different machines. 

e Scalability, being able to easily deploy additional supervisors or withdraw them when they are 
not required. 

e  Easyadaptation to new requirements which allows to easily tailor the characteristics of the XL- 
SIEM Engine to specific requirements of the infrastructure where it is deployed. 


Figure 8 shows the containers deployed for the installation of an XL-SIEM agent, representing the 
following containers: 


e Storm container, which executes the Storm topology that supports the XL-SIEM engine. There 
are four containers in this group: 
o Supervisor in, the container that executes the Storm supervisor, which manages the 
workers that execute specific tasks. This container uses a de dedicated socket port, 
which is used to receive events from the XL-SIEM agents. 
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o Storm ui (optional), a supporting container used for manging the processes of the 
topology, check performance, etc. A dedicated TCP port is used for this purpose. 

o Nimbus is the node of the Apache Storm topology that control que activities carried 
out by supervisors (in this case, just one supervisor). This is done through a dedicated 
TCP port. 

o BDrpc, a container that manages the communication between the storm nodes, using 
a dedicated TCP port. 

e Zookeeper container, which controls the status of the nodes of the Storm topology, using 
several ports for this purpose. 

e A web container (xlsiem web SDN-microSENSE) which contains the XL-SIEM dashboard for 
managing it and visualizing events and alerts, using the port 80 (8080 for HTTPS) 

e A RabbitMQ container (optional) which can be used to support communications to and from 
the XL-SIEM with other components (for example, to export alerts). Details about this 
container will be given in Section 4.2.8 

e A database container, used by the storm nodes to store events, alerts, configuration, etc, 
based on MariaDB, typically using the mySQL TCP port. 


xlsiem-rabbitmq 


xlsiem.db sdnmicrosense 


Figure 8. Docker containers deployed for an XL-SIEM installation! 


It is worth noticing that all ports aforementioned are just used internally between docker containers, 
not being visible outside of the machine that hosts these containers. The exception is the HTTPS port, 
which is visible for the access to the web dashboard. 


Dockerizing the main components of the XL-SIEM provide with huge advantages in term of deployment 
alternatives. The supervisor in and the database containers are the ones that demand more resources, 
the former in terms of computation and the latter in terms of storage and network connectivity (i.e., 
max number of concurrent connections to the database). Additionally, not all containers require 
connectivity with all containers. These dependencies, shown in Table 1, allows several deployment 
alternatives that can be adapted to the characteristics of the infrastructure to monitor. 


Table 1. Connectivity dependencies between XL-SIEM containers 


Zookeeper | Nimbus Supervisor | Drpc | Storm ui | Database | Dashboard 
Zookeeper YES YES NO NO NO NO 
Nimbus YES YES YES YES NO NO 
Supervisor | YES YES YES YES YES NO 
Drpc NO YES YES YES NO NO 
Storm ui NO YES YES YES NO NO 
Database NO NO YES NO NO YES 


1 Ports hidden for security reasons 
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Dashboard | NO NO NO NO NO YES 


For example, there can be four main areas of deployment: 


Area 1: Dashboard. This is the less critical container in terms of connectivity with other containers. The 
dashboard will interact just with the Database, which is used by the system administrator to visualize 
events, alerts or to configure the XL-SIEM. This container needs to be accessible with a Web Browser, 
which requires to have a TCP port open (which is mapped to the HTTPS port of the container). HTTPS 
connections are used to interact with the dashboard. 


Area 2: Database. This container needs to be visible both to the Dashboard and to the Supervisor (or 
supervisors if there are more than one). The connection to the dashboard is required because it is its 
source of information for events, alerts and configuration data. With the supervisor the connectivity is 
required because it is used by its workers to store events and alerts, to read correlation rules and the 
configurations to use at the Storm topology. As it contains critical data, it should be deployed in a 
secure location, ensuring that just the Dashboard and Supervisor containers can access to it. 


Area 3: Storm containers (Nimbus, Supervisor, Drpc, Storm ui). These are the core of the topology, 
especially the Nimbus, the Supervisor and the Drpc. They are basically considered as processing 
containers. They don't store persistence information nor need to be exposed to external consumers 
like the Dashboard does (except when alerts are exported to RabbitMQ queues as will be described 
later in this document). However, it has higher computational requirements, especially in terms of CPU 
and RAM (depending on the deployment used it can require a minimum of 4 CPU cores and 6GB RAM). 
The container Storm ui is optional and not really required for the Storm topology to work correctly, 
although it provides with important management information (for example, to check the number of 
workers running at any moment or the amount of RAM memory used). 


Area 4: Zookeeper. This component requires connectivity with the Storm containers basically to check 
whether they are working properly. This node doesn't store or use information from the database. It 
also doesn't have major computational resources. 


Figure 9 summarizes the requirements required for the container included in each are in terms of 
security, connectivity with external components, computational resources and network resources. 
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Figure 9. Comparison of requirements for deploying XL-SIEM containers 


A different combination of the XL-SIEM containers can be set-up, which depends on the specific needs 
of the infrastructure where it is to be deployed, such as in the EPES domain considered in SDN- 
microSENSE. 


3.2 Deployment considerations in SDN-microSENSE 

The XL-SIEM solution is broken down in several components which are interconnected employing 
different technologies (Figure 10). These technologies have been chosen having into account a 
different aspect of the communication of information flows where asynchronous messages play a main 
role. The following figure is a simplified diagram where only communication technologies involved by 
the XL-SIEM are depicted. 


c— TCP socket 7 AMQP EO) 
XL-SIEM engine ——— —— Ba 
SS Log master E —| XL-SIEM agent H- 
Ay - ri 
Log daemon [FF (server) 8 Alarm 
(client) TSL Master log Nightwatch Logs 
ii AMQP 
TCP socket 
Normalized Event 


B CLS Nightwatch AMQP (RabbitMQ) 
Remote log 


Raw log 
pia 


Figure 10. XL-SIEM infrastructure resources 


The XL-SIEM solution requires the deployment of XL-SIEM agents into the EPES infrastructure, as well 
as log daemon. In this deployment, the following issues must be considered: 


e Log daemon installation. To get remote logs is needed running a daemon in the EPES for IDPS 
detectors, Honeypots, Access control and data request and Machine learning detector 
components. This daemon acts like a file watcher which detects a log updates and sends it to 
the Log master which gathers all of those updates in a master log. For each one of these 
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systems, a daemon has to be installed and configured indicating the log master server address 
and the local folders to watch out. 


e One XL-SIEM agent for each subnetwork. Every subnetwork has to contain an instance of the 
XL-SIEM agent to be monitored. Depending on the type of communication a specific agent has 
to be deployed and configured. 


e XL-SIEM engine port access. Due to the communication between the XL-SIEM agent and the 
XL-SIEM engine it is needed to establish communication connectivity between them. 


To deal with a secure deployment environment, the XL-SIEM component must compel not only the 
security of each component in an isolated way, but also how to achieve secure communications, giving 
emphasis on the DMZ and not on DMZ environments. The communication security ranges from: 


e Communication path constrains. The communication path should be constrained to 
guarantee source and target match with suitable IP address and service port. This is a common 
rule that could be easily configured of the mean of Firewalls and even the SDN switches 
themselves. For this, it is recommended to establish the host's IP where the XL-SIEM agents 
will run. Although, a major control could be by the MAC usage rather than the IP address XL- 
SIEM agent. For this, it is required to obtain the flows belonging to SDN switches and firewalls 
allow the message bypass between IP/port sources and IP/port targets. 


e SDN network reinforcement. The path from the information sources services up to each of 
intermediate component, such as daemon logs, master log, XL-SIEM agent, 
XL-SIEM engine, AMQP broker, has to count on at least two paths by the mean of increase the 
number of SDN switches in order to the SDN self-healing algorithm is able to find out different 
alternatives when needed. 


e Warranty band width. The SDN network has to be configured to warranty a continuous 
information flow of messages. Fortunately, this is straightforward by the mean of the own SDN 
switches. 


e Secure protocols. The communication of logs, events and alarms have to use secure protocols 
and certifications. 


e Operation network avoiding. Most security recommendations in the industrial network, very 
similar to ICT networks in Electric grids, suggest minimizing the impact of any solution in the 
operational network. Having this in mind, the log information should not go through the same 
network where spring protocols travel, in favour of informational networks devoted to 
production and business purposes. 
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Figure 11. ISA 95/98 standard - Industrial networks 


Regarding the communication implementation, the technology employed for the event notification is 

planned to be by sockets whereas the alarm communication will be by AMQP (RabbitMQ). A 

technology comparison is given in Table 2. Both technologies are more suitable for the type of 

communications present in XL-SIEM. In fact, these communications comply with the following 

properties: 

e Asynchronous paradigm. Both XL-SIEM agents and the XL-SIEM engine do not need any response 
after an event or alert notifications have been sent. 

e Streaming flow. An enormous amount of event and alerts are supposed to be continuously sent. 
While the connection is alive, multiple messages can be sent. 

e Simple message format. Notification messages are very simple. 


Table 2. Communication technologies comparison 


REST... map... Pseke O 
Ys No — pe — Ne  — — 1] 


R 
e 


S 
Synchronous / NN Synchronous / 
Asynchronous Asynchronous 
PC Publish-subscribe Full duplex 
Queuing 
s 


No guaranteed No guaranteed 


No | 


(*) the publisher establishes a real point to point connection with the AMQP broker regardless the subscriber availability. 
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To understand the convenience of streaming flow it is relevant to describe its differences from 
SOAP/REST services communications (Figure 12). The main difference is focussed on the connection 
time spent by each message sending. In both SOAP and REST cases, it is needed to make a TCP 
connection to send a single message. As it is known, the connection time is not that negligible. In 
contrast, in a streaming communication the connection is established only at the beginning, after that 
you can keep a continuous flow of messages, even in full-duplex way. 


SOAP, REST Streaming TCP IP/Socket 
service communication 


TCP Server 
Socket () 
bind() 
$ 
TCP Client ea 
= accept () 
Single eT € connection establishment | 
3 
Md pol Multiple write() Loo EMEN iL read() 
session ; | 
messages per "- E 
session read() 
Em end-of-file notification HE 
close () 


Figure 12. SOAP/REST vs Streaming flow 


The AMQP and TCP Socket supply the most features needed for XL-SIEM communications. TCP Socket 
is the alternative chosen for communication between XL-SIEM agents and the XL-SIEM Engine mainly 
because the TCP Socket software library is simpler than the AMQP library, which is adequate when the 
source and target work closely. However, the communication between CLS Nightwatch and the XL- 
SIEM agent uses AMQP (RabbitMQ) because to the broker usage allows more flexibility of future 
clients. 


4 Monitoring and Incident Detection in SDN-microSENSE 


4.1 SDN-microSENSE protocols and threats 

The support of incidents associated to EPES specific protocols is one of the main innovations 
incorporated in the XL-SIEM when integrated in the XL-EPDS component of the SDN-microSENSE 
architecture. Supporting these protocols opens up the XL-SIEM to a myriad of new possibilities in terms 
of incident detection, new domains of application and new business opportunities. The following 
subsections give an initial overview of these protocols, which will be deeply detailed in the rest of WP5 
tasks where attack detectors are developed (T5.2, T5.3 and T5.4). 


4.1.1 Modbus 

Modbus protocol was designed by Modicon in 1979 and since then constitutes the most widely 
deployed industrial communication protocol. It operates at layer 7 of the Open Systems Interconnection 
(OSI) model that means it is an application layer messaging protocol. The Modbus protocol is based on 
the communication of client/server between devices connected on different types of networks. The 
client sends request to the server and according to the request, the server perform an action and send 
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a replay, O. The reserved port of the Modbus protocol is 502. The operation of the Modbus protocol is 
depicted in the Figure 13. 


Master 


Send 
(Function, Code, Request] 


uum Send 


[Function, Code, Response] 


Figure 13. Description of the Modbus protocol operation 


The Modbus slave provides to the Modbus master the following objects; the discrete input that 
constitutes a type of read only Boolean variable, the coil that constitutes a type of read-write Boolean 
variable, the input register that constitutes a type of read only integer and the holding register that 
constitutes the type of read and write integer. Table 3 describes all the function types, the function 
names and the function codes of the Modbus protocols. The most commonly used functions codes of 
the Modbus protocol are the following. The function code 1 named read coil, the function code 2: read 
discrete input, the function code 3: read holding registers, the function code 4: read input registers, 
function code 5: write single coil, function code 6: write single holding register, function code 15: write 
multiple coils and function code 16: write multiple holding registers. The Modbus protocol is suitable 
to communicate Programmable Logic Controllers (PLCs) and the remote terminal unit RTUs with a 
Supervisory Control and Data Acquisition (SCADA) system. 


Table 3. Description of the Function types, the Function names and the corresponding Function codes for the Modbus protocol 
[Knapp+14] 


Function Type Function Name Function 
code 
Data Bit access | Physical Discrete inputs | Read discrete inputs 2 
access Physical coils Read coils 1 
Write single coil 
Write multiple coils 15 
16-Bit Physical Input registers Read input register 4 
access Physical output Read multiple holding registers 3 
registers Write single holding register 6 
Write multiple holding registers 16 
Read/write multiple registers 23 
Mask write registers 22 
Read FIFO Queue 24 
File record access Read file record 20 
Write file record 21 
Diagnostics Read exception status 7 
Diagnostic 8 
Get com event counter 11 
Get com event log 12 
Report slave ID 17 
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Other Encapsulate interface transport 43 


According to Drias et al. O, the most cited attacks of the Modbus TCP protocols affect the mechanisms of 
the protocol in terms of interception, modification and generation. They assume that the main attacks 
associated with the Modbus protocol are the following; the Broadcast message spoofing, the Baseline 
response replay, the Direct slave control, the Modbus network scanning, the Passive reconnaissance, the 
Response delay and the Man in the Middle. More specifically, the Broadcast message spoofing is the 
type of attack that sends faked broadcast messages to Modbus server in the device. The Baseline 
response replay involves recording Modbus messages between a Modbus client and a Modbus server. 
The Direct Slave Control attack aims to lock out a master (client) and controlling one or more field 
devices. The Modbus Network Scanning is the type of attack that sends benign messages to all possible 
addresses on a Modbus network to obtain information about field devices. The Passive Reconnaissance 
involves passively reading Modbus messages or network traffic. This attack helps the attacks to profile 
the process details by reconstructing the device application. The Response Delay attack involves delaying 
response messages so that the master receives out-of-date information from slave devices. This attack 
intends to sabotage the supervision in case that the command in the Modbus message is a diagnostic 
message. The Man in the Middle attack (MITM) involves introducing a computer with the appropriate 
(serial or Ethernet) adaptors to an unprotected communication link. The MITM device is embedding a 
client and Modbus server; therefore, it can read, modify and fabricate Modbus messages to or from the 
device. This attack is the most dangerous attack on Modbus protocols as it can take the full control of 
both parties of protocol; the client and the server in the same time. 


Based on the most commonly cited attacks for the Modbus protocol and assuming the threat 
classification that is provided by ENISA O different attack scenarios will be considered to simulate the 
abnormal traffic of the Modbus protocol and based on the Smod modular framework?. The attack 
scenarios concern the following procedures: Unauthorized access, Failure of devices and systems, 
Manipulation of information, Information leakage, Network Reconnaissance, Information Gathering and 
DoS. 


More specifically, the attack scenario WriteSingleCoils aims to change the value of a coil. The 
WriteSingleRegister is the scenario that change the values of a single holding register and the UID brute 
force attack describe the type of the Brute force attack against PV/Battery inverters. All of the scenarios 
that have been described above belong to category that contains attacks related to the Unauthorized 
Access, the Failure of devices and systems and the Manipulation of information. 


Taking into consideration the categorization that related to the unauthorized access and information 
leakage four attack scenarios are going to develop”. The first scenario named ReadCoils, constitutes the 
attack scenario that reads the value of a specific coil. The ReadDiscretelnput is the scenario that extract 
the values of the discrete inputs supported by the target. The ReadHoldingRegister is the type of attack 
that returns the values of the holding registers supported by the target system and the fourth attack in 
this category is the ReadInputRegister that reads the values of the input registers. 


? Smod modular framework homepage, https://github.com/Joshua1909/smod 
3 https://github.com/CanadianlnstituteForCybersecurity/CICFlowMeter 
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supported by the target system. The Discover identifies whether the Modbus runs in the target system 
and the Modbusclient describes the scenario that exploits a Modbus vulnerability that allows to an 
unauthorized actor to read or write against the targeted Modbus slave. 


Finally, two scenarios that associated with the DoS attacks will be developed. The WriteSingleCoils 
constitutes the type of DoS attack scenario, which send continuously malicious Modbus packets 
(function code 5) to the target system. In a similar way, the WriteSingleRegister constitute also a DoS 
attack, which sends continuously malicious Modbus packets (function code 06) to the target system. 


Table 4 summarizes the type of scenarios that will be developed and the corresponding classification 
based on ENISA threat taxonomy and on the CAPEC classification. 


Further details about this protocol, attacks and detectors are given in D5.2. 


Table 4. Description of the attack tools and their corresponding threats for the Modbus protocol. 


Threat Description of the Threat ENISA Threat CAPEC 
taxonomy classification 
Function/ Aims to change the value of | Unauthorised Access, 180 
-— . a coil Failure of devices and 
writeSingleCoils f : 
systems, Manipulation 
of information 
Function/ Changes the values of a Unauthorised Access, 180 
"un . single holding register Failure of devices and 
writeSingleRegister : : 
systems, Manipulation 
of information 
UID brute force attack Unauthorised Access, Unauthorised Access, 112 
against PV/Battery Failure of devices and Failure of devices and 
inverters' RPI systems, Manipulation of systems, Manipulation 
information of information 
Function/ readCoils Reads the value of a Unauthorised Access, 180 
specific coil. Information leakage 
Function/ Extracts the values of the | Unauthorised Access, 180 
readDiscretelnput discrete inputs supported | Information leakage 
by the target. 
Function/ Reads the values of the Unauthorised Access, 180 
readHoldingRegister | input registers Information leakage 
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Scanner /getfunc Discovers the functions Network 309 

codes supported by the Reconnaissance and 

target system Information Gathering 
Scanner /uidc Enumerates the UIDs Network 309 

supported by the target Reconnaissance and 

system Information Gathering 
Scanner /discover Identifies if Modbus runs in | Network 309 

the target system Reconnaissance and 

Information Gathering 

Scanner Exploits a Modbus Network 309 
/Modbusclient vulnerability that allows to | Reconnaissance and 

an unauthorized actor to Information Gathering 

read or write against the 

Modbus slave targeted 
Modbus /dos Sends continuously DoS 125 
/writeSingleCoils: malicious Modbus packets 

(function code 5) to the 

target system 
Modbus /dos Sends continuously DoS 125 
/writeSingleRegister: malicious Modbus packets 

(function code 06) to the 

target system 


4.1.2 DNP3 

DNP3 [VOWM1+20] is a reliable protocol applied largely in the Critical Infrastructures (CIs) in the US. 
In the Electrical Power and Energy Systems (EPES), DNP3 is adopted to transfer messages between 
master devices and outstations. It supports several topologies, including a) point-to-point, where an 
outstation and one master communicate with each other, b) multiple-drop, where several masters and 
outstations interact each other and c) hierarchical interface, where an entity can operate with both 
roles. DNP3 includes three layers: a) link layer, b) transport layer and c) application layer. The link-layer 
offers addressing services, multiplexing, data fragmentation, error checking and link control. On the 
other side, the transport layer is used as in the case of the Open Systems Interconnection (OSI) model, 
and it is represented with one byte utilised for fragmenting the DNP3 packets. Finally, the application 
layer defines a set of functional commands used for managing and controlling the EPES entities, such 
as Remote Terminal Units (RTUs), Programmable Logic Controllers (PLCs), Intelligent Electronic Devices 
(IEDs) and smart meters. Apart from the DNP3 serial line communication, DNP3 can be used over 
TCP/IP where in this case, the aforementioned DNP3 layers are incorporated into the application layer 
of TCP/IP. 


According to O. Igbe et al. [UOWM2+20], various cyberattacks target directly the DNP3 protocol with 
significant consequences (Table 5). 
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Table 5. Description of the attack tools and their corresponding threats for the DNP3 protocol. 


Threat 


Description of the Threat 


DNP3 Enumerate 


It is a reconnaissance attack aiming to identify whether the DNP3 
service operates in the target systems. 


DNP3 Info 


It is another reconnaissance attack which obtains useful diagnostic 
information about the utilisation of DNP3. 


DNP3 Disable Unsolicited 
Messages Attack 


It is unauthorised access attack, which transmits to an outstation a 
DNP3 packet with the function code 21, thus disabling all unsolicited 
messages. Therefore, the outstation will not be able to send any alarm 
message to the master devices 


DNP3 Cold Restart | It is another DNP3-related unauthorised access attack, which aims to 
Message Attack restart an outstation. 

DNP3 Warm Restart | Similarly, to the previous case, it intends only to restart the DNP3 
Message Attack service in the target outstation 


The aforementioned DNP3 cyberattacks are addressed efficiently by the XL-SIEM sensors. Further details 
about this protocol, attacks and detectors are given in D5.2. 


4.1.3 IEC 60870-5-104 


IEC-104 [UOWM3] is a communication protocol provided by the IEC 60870-5 standard for monitoring 
and controlling automated processes in EPES applications by utilizing the transport capabilities offered 
by TCP/IP. In particular, it utilizes by default the TCP port 2404. Figure 14 illustrates the payload of this 
protocol which is named Application Protocol Data Unit (APDU). 
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Figure 14. IEC 60870-5-104 Protocol 
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APDU consists of two parts, namely 1) Application Protocol Control Information (APCI) and 2) Ap- 
plication Service Data Unit (ASDU). APCI includes the start character (68h), the length of APDU and 
four Control Fields (CFs). On the other side, ASDU is an optional part which is determined by the format 
of APDU. In particular, APDU can take three formats: 1) I-format, 2) S-format and 3) U- format. The I- 
format is used to execute numbered information transfers and always includes ASDU. The S-format is 
used to perform numbered supervisory functions and comprises only APCI. Finally, the U-format is 
responsible for performing unnumbered control functions and it also includes only APCI. The format 
of APDU is determined by CF1 and specifically by its two last bits. If the two last bits of CF1 are equal 
to 00, then the I-format is used. Accordingly, if the last bits of CF1 are equal to 01, then the S-format 
is applied. Finally, if the aforementioned bits are 11, the U-format is used. Concerning the ASDU, it 
includes the following fields: 1) Type Identification, 2) Structure Qualifier (SQ), 3) Number of Objects 
or Elements, 4) T, 5) P/N, 6) Cause of Transmission (CoT), 7) Originator Address (ORG), 8) ASDU 
Address, or Common Address of ASDU (CoA), 9) Information Object Address (IOA), 10) Information 
Elements, 11) Time Tag. The Type Identification determines the type of information objects. All 
information objects of an ASDU must have the same type. SQ specifies how the information objects 
and elements are structured. The Number of Objects or Elements field denotes the number of 
information objects or elements depending on the value of SQ. Accordingly, T defines those ASDUs 
which are dedicated for testing. P/N determines the positive or negative confirmation of an activation 
command. CoT directs ASDU to specific tasks and simultaneously interprets the data received by the 
destination side. ORG is an optional field and undertakes to explicitly define the identity of the 
controlling station (i.e. MTU). CoA defines the address of MTU or RTUs at the application layer. IOA 
determines the address of an information object. Information Elements provide and transmit specific 
information and finally, Time Tag provides time information. 


The functionality of the IEC-104 protocol relies on the TCP/IP, which itself includes multiple security 
issues. Moreover, IEC-104 does not include any authentication and authorisation mechanism, thus 
enabling potential Man-in-The-Middle (MiTM) and unauthorised attacks. In particular, Table 6 
describes the attacks can be directly performed against IEC-104. 


Table 6. Description of the attack tools and their corresponding threats for the IEC-104 protocol. 


Threat Description of the Threat 
M SP NA 1 DoS | The specific cyberattack sends continually to the target system M SP NA 1 
packets 


C SE NA 1 Dos | This cyberattack floods the target with C SE NA 1 packets 
C SC NA 1 DoS | Similarly, this attack sends continuously to the target system 
C SC NA 1 packets 


C SE NA 1 This cyberattack constitutes and unauthorised access, transmitting to the 
target system C SE NA 1 packets 

C CI NA 1 This cyberattack send unauthorised C CI NA 1 packets to the target system 

C SC NA 1 This cyberattack is another unauthorised access attempt related to IEC-104, 


transmitting C SC NA 1 packets to the target 
C CI NA 1 DoS This cyberattacks constitutes a Dos related to IEC-104, transmitting 
continuously C CI NA 1 packets to the target system 


The aforementioned IEC-104 cyberattacks will be addressed efficiently by the XL-SIEM sensors. Further 
details about this protocol, attacks and detectors are given in D5.2. 
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41.4 IEC61850 

International Electrotechnical Commission (IEC) 61850 [UOWM1-420] is an abstract international 
communication standard for EPES systems and particularly for SCADA applications, defining a 
hierarchical, object-oriented data representation model. In particular, each asset is characterised by a 
data model composed of naming, diagnostic and configuration information. The purpose of this data 
model is to facilitate the information exchange among the EPES assets, without referring to their 
functional and technical details. The IEC 61850 stack consists of four types of messages: a) 
Manufacturing Messaging Specification (MMS), b) Generic Substation State Events (GSSE), c) Generic 
Object-Oriented Substation Events (GOOSE) and d) Sampled Measured Values (SMV). IEC 61850 is also 
used for the control, protection and measurement functions of a substation. These functions are 
implemented in Intelligent Electronic Devices (IEDs), which can house one or more of these functions. 
In turn, each of these IEDs must interact with the functions of the IEDs in the rest of the system. Figure 
15 shows a typical architecture of a substation where different types of IEDS (SCU* and BCU?) interact 
each other in a communication network. 
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Figure 15. Typical general view of a primary substation 


The IEC 61850 standard allows that the control of the substations becomes independent of the 
manufacturers, being able to interconnect and replace devices belonging to different manufacturers. 
To achieve this objective, the standard is based on three key principles: 


e = It defines a unified information model with a hierarchy of names and specific data structures to be 
used in the different devices. 

e |t defines a communication protocol and common functionality. This protocol is an agreed 
language for all equipment in the system. The protocol is designed to be able to send the necessary 
information to the automated system while maintaining time and availability requirements. 


4 Substation Control Unit. 
5 Bay Control Unit. 
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e It establishes an XML-based configuration file format and a set of formats and tools to facilitate 
automation and configuration tasks within the engineering process. 


Data Modelling 
IEC 61850 information model is based on two main levels of modelling: 


e The breakdown of a real device (physical device) into logical devices. A logical device represents a 
group of typical automation, protection or other functions. 
e The breakdown of a logical device into logical nodes, data objects and attributes. 


The functions executed by the real devices are modelled by the logical nodes. The combination of 
several of these logical nodes makes up a logical device, and depending on their functionality, logical 
nodes contain a list of data objects with their corresponding data attributes. Figure 16 gives an example 
of how each level is included into the upper level. Simple data types (integers, booleans, etc.) are 
organized into composite data types (quality, scale), and these, in turn, are grouped to form the 
supported data types CDCs (measurement, controllable data, status information, etc.). 


LDx 


Logical Device 


IEC 590/13 


Figure 16. IEC 61850 Data modelling. Source IEC/TR 61850 


Communication Protocols 
IEC 61850 offers three types of communication models: 


e Client/server type communication service model. This model is used for the MMS that sends its 
messages through TCP connections (Layer 4 OSI) It is used for the exchange of application data, as 
well as device configuration parameters or monitoring data. 

e Sample Values (SMV) model for multicast measurement values. This model is used to provide rapid 
communication of measurement, protection and control values. It works through Ethernet (Layer 
2 OSI) following a publisher-subscriber model. 


© SDN-microSENSE consortium Page | 32 
Public document 


e SDN-uSense 
D5.1 


Version 1.5 


e Fast and reliable system-wide distribution of data based on a publisher-subscriber model. This 
model is used for real-time transmission of critical events (GOOSE messages) and like Sampled 
Measured Values, through multicast Ethernet (Layer 2 OSI). 


In the context of the SDN-microSENSE, XL-SIEM focuses on GOOSE and particularly on the attacks listed 
in Table 7. 


Table 7. Description of the attack tools and their corresponding threats for the IEC 61850 protocol. 


Threat Description of the Threat 

GOOSE DoS This refers to a GOOSE-related DoS attack, which floods the target system with 
GOOSE messages, to block legitimate IEDs from accessing resources 

Data This is an unauthorised access attack, which injects malicious GOOSE packets, 

Manipulation aiming to impact the grid stability or to cover unauthorized changes 

Message This attack refers to the hijacking of the GOOSE packets by modifying their 

Suppression header, thus hindering the EPES assets to receive critical GOOSE messages 

Disturbance It refers to electricity-related disturbances and faults that might occur 


Further details about this protocol, attacks and detectors are given in D5.2. 


4.1.5 IEEE C37.118-2 

The IEEE C37.118-2 standard [IEEEC37+11] defines the communication framework for data transmitted 
between Synchrophasors, which are used for measuring electrical quantities between different parts 
of the power system. It combines other technologies such as the Global Positioning system (GPS). They 
also combine PMUs (Phasor Measurement Unit) and PDCs (Phasor Data Concentrator) and additional 
equipment for visualization and monitoring (Figure 17). At substations, PMUs takes measurements, 
adding a precise timestamp using a GPS device. These PMUs send their measurements to a PDC 
towards a control centre. 
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Figure 17. Synchrophasor communication system overview (taken from [Khan+16]) 


The format of the messages exchanged are specified in the standard, but it doesn't specify the 
transport protocol, thus missing any security feature that can be implemented at the transport level. 
Figure 18 depicts the message format for the IEEE C37 protocol. It includes synchronization words, 
framesize for the number of bytes in the message, the id of the Synchrophasor (ID), the timestamp in 
the SOC and FRACSEC fields, the DATA fields for the measurement and a CRC in the CHK field. 
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Figure 18. Message format of the IEEE C37.118-2 standard (taken from Khan+16]) 


There are different types of messages that are specified in the IEEE C37 standard: (1) data messages, 
for sending measurements, (2) configuration messages for sending information about how to process 
information, (3) header messages, which include human readable information about different aspects 
such as the source of the data, filtering, etc, and (4) command messages, that allows to trigger or stop 
the transmission of information from Synchrophasors. The communication protocol to use is not 
specified in the standard, although typically it relies on RS232 or IP, with the possibility of using both 
TCP or UDP. 


As it has been mentioned before, the IEEE C37 standard does not specify anything about security. 
Therefore, it is exposed to several cyber-attacks, a described in Table 8: 


Table 8. Description of the attack tools and their corresponding threats for the IEEE C37.118-2 protocol 


Threat Description of the Threat 
Reconnaissance allows to discover vulnerabilities in the Synchrophasors components. These 
Attack attacks are typically targeting the communication network by exploiting 


eavesdropping in the network traffic, which allows to capture information 
such as locations, names of substations, etc 
Authentication/Acc | allows to get control of devices and resources. In IEEE C37 this is critical 


ess Attack because no authentication mechanism is specified. The control of PMUs can 
be taken just by intercepting packets, injecting malicious ones or replaying 
them 

Man In The Middle | Derived from the Authentication/Access Attack is the Man in the Middle 

Attack (MITM) Attacks, which allows an attacker to assume the role of one of the 


communication devices impersonating one of the peers, intercepting 
messages and altering them for its malicious purposes. In IEEE C37 messages, 
intercepting and altering configuration messages are a serious threat that can 
be easily carried out 


Replay or These attacks rely on MITM attacks to replay communications, altering the 
Reflection Attack content to lead to incorrect decisions 

Denial of Service This type of well-known attacks can be carried out in IEEE C37 by targeting 
Attack the communication channel between PMUs and PDCs or between substations 


and control centres. This is done by exhausting any of these components with 
messages generated by malicious attackers. As there is no security 
mechanisms specified, there is no way to check if a message is legitimate or 
not, thus being processed by the Synchrophasor, which becomes stalled due 
to the need of processing an abnormal amount of messages 
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4.1.6 Other relevant protocols within the EPES domain 

Apart from the domain specific protocols specified before, the XL-EPDS also considers additional 
protocols that are of interest for the EPES domain. The following subsections details two of them. 
These protocols are further detailed in D5.2 


4.1.6.1. MQTT protocol 

The Message Queuing Telemetry Transport (MATT) protocol is a Client Server publish/subscribe 
messaging transport protocol. Andy Stanford-Clark and Arlen Nipper originally designed the MQTT but 
currently is in the OASIS (Organization for the Advancement of Structured Information Standards) and 
has standard defined in ISO/IEC 20922: 2016 O, O. It constitutes a standard protocol that has many 
assets; it is open, simple to use and easy to implement. Moreover, it is used widely for communication 
in Machine-to-Machine (M2M) and Internet of Things (loT) system in case that required limited 
resources because of its lightweight attribute and the small bandwidth requirements [Banks+14]. 


MATT has great capabilities for the SCADA systems and in the smart grids, especially if the SCADA and 
the loT are required to interact. Since the loT becomes essential for SCADA systems, the MQTT protocol 
would be an interesting candidate to replace more common protocols that are not able to adapt to 
the loT. An important feature of the MQTT protocol is the Quality of Service (QoS) variable. The QoS 
variable determines how a message is sent and how the receiver responds to the message. Three levels 
of the variable can be set to examine the quality. The level O denotes that the message has been sent 
once and no response will be sent. The level 1 guarantee that the message has been reached to the 
receiver at least once. Moreover, Level 2 means that every message is guaranteed to be sent and 
received precisely once. 


Multiple attack scenarios have been assumed in the literature to examine the vulnerability of the 
MATT protocol. More specifically, Andy et al., O examined scenarios that associated with the 
exploitation of data privacy, authentication, data integrity and the existence of Botnets over MQTT 
protocols. Ozgur et al., O examined three different scenarios at the communication level; the Message 
Integrity Attack (MIA) according to this scenario the bytes of data received by the subscriber of the 
destination could be changed by a Man In The Middle attack (MITM). The Delay Attack (DA) that 
describes the situation that data is delayed due to a denial of service (DoS) attack and obtain as a result 
congestion problems. Finally, the Packet Drop Attack (PDA) that describes the situation that data is 
entirely lost due to a DoS attack. 


Taking into consideration the aforementioned main attacks, four different attack scenarios will be 
developed to produce the abnormal traffic for the MQTT protocol®. The MITM attack scenario that 
intercepts the communications, filters and dumpers the measurement that are send or received. The 
second scenario is related to the Unauthorized Access, Failure of devices or systems and Manipulation 
of information. The Unauthorised publishing to smart devices is the scenario that provides the ability 
to the attacker to connect to the broker in order to subscribe in all the topics and to publish 
unauthorized commands. Furthermore two DoS scenarios will be developed; the DoS attacks against 
MATT broker that associates with flood connection that sends multiple connection messages to 
exhaust server resources and the DoS that associates with the large payload attack that publishes spam 
messages repeatedly to a specific topic in comparison to the legitimate users that cannot publish this 


5 https://github.com/CanadianInstituteForCybersecurity/CICFlowMeter 
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messages. Table 9summarizes the type of scenarios that will be developed, and the corresponding 
classification based on ENISA threat taxonomy and on the CAPEC classification. 


Table 9. Description of the attack tools and their corresponding threats for the MQTT protocol. 


Threat Description of the Threat ENISA Threat CAPEC 
taxonomy classification 
MITM attack Attacker intercepts the Man in the middle 94 
communications, filters and 
dumpers the measurements 
send/received by gateway 
Unauthorized Attacker connects to the broker, | Unauthorized Access, 180 
publishing to subscribes to all topics and Failure of devices and 
smart devices publish unauthorized Systems, Manipulation 
commands of information 
DoS attacks Attacker sends multiple DoS 125 
against MQTT connection messages to exhaust 
broker: Connect server resources 
flood 
DoS attacks Attacker publishes spam DoS 594 
against MQTT messages repeatedly to a 
broker: Large specific topic, legitimate users 
payload attack cannot publish 


4.1.6.2 NTP protocol 

The Network Time Protocol (NTP) is one of the mostly used protocols for time synchronization. A client- 
server model is the type of model that usually describes the NTP protocol. The NTP sends and receives 
timestamps using the User Datagram Protocol (UDP) and reserves the port number 123. The 
synchronization of time in smart grids plays a key role, since a common time reference is essential to 
correlate power quality and to provide the coordination for any distributed actions O. Since the smart 
grids can have many medium and low voltage substations, the time synchronization should be 
compatible among the devices. When an NTP attack begins, the offset gets significantly higher, it takes 
a few exchanges before the victim adapts its system time. After the successful procedure of the attack, 
the victim's system time jumps to the time proposed by the attacker and the offset returns to normal 
values O. 


Malhotra et al., O discussed the main risks that network attackers can exploit to alter the time on client 
systems that use NTP protocol and categorize the attacks into two categories. The first category is the 
“on-path attacks” where the attacker occupies a privileged position between the server and the client 
or hijacks the traffic. The second category of attacks is the “off-path attacks” where the attacker does 
not observe the traffic between the client and the servers and can be anywhere in the network. The 
“small-step-big-step attack” constitute an “on-path attacks” that shifts clocks when clients are unlikely 
to notice. The Kiss o” Death (KoD) packet attack is the type of the “off-path attack” that can disable 
NTP at a victim client upon receipt of the spoofed KoD, the client stops querying its servers and stops 
updating its clock. 


Assuming the main attacks for the NTP protocol the main attack scenarios that will be developed in 
terms of time manipulation process. More specific, will be developed the clock time skimming attack 
and the KoD packet elimination attack. The Table 10 summarizes the attack scenarios that will produce 
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the abnormal traffic for the NTP protocol and corresponds them to ENISA threat taxonomy and to the 
CAPEC classification. 


Table 10. Description of the attack tools and their corresponding threats for the NTP protocol. 


Threat Description of the Threat ENISA Threat CAPEC 
taxonomy classification 
Time manipulation | Clock time skimming attack Time manipulation 172 
Time manipulation | Kiss o' death packet Time manipulation 172 
elicitation attack 


4.2 SDN microSENSE security sensors 

The protocols described in Section 4.1 are supported by the XL-SIEM thanks to the integration of logs 
produced by security sensors capable of monitoring such protocols. Within SDN-microSENSE several 
tools have been developed and integrated with the XL-SIEM as part of the XL-EPDS subsystem of the 
SDN-microSENSE architecture. The following subsections introduce these security sensors which will 
be deeply detailed in the tasks where they are developed. 


4.2.1 EPES Honeypots 

In the context of the SDN-microSENSE project, three honeypots of relevant industrial protocols: IEC 
61850, IEC60870-5-104, Modbus have been developed. Each one of these three honeypots are 
prepared to have a direct connection with XL-SIEM Agent component. The Rsyslog interface exposed 
by XL-SIEM agent is the communication channel selected for event communication. Rsyslog is run into 
honeypot machine to recollect inputs to event file /var/log/honeypot.log and output the results to 
XL-SIEM by means of a secure connection. 


Each developed honeypot has a different format for the events. Following a description of these format 
for each honeypot is shown, more information of these can be found in D3.3 [SDN33] 


e 1EC61850 Honeypot: 
The format of the log for this honeypot is (Table 11): 


e eventld: Identifier of the event 

e Name: Name of the event 

e Timestamp: Timestamp with the exact time in which the event occurred. The format 
of the timestamp is yyyy-MM-dd'T'HH:mm:ss*SSSZ 

e Parameters: An array of parameter structures with additional information related to 
the event. The table presents the list of the event registered and the parameters 
associated 


Table 11. Log taxonomy for the IEC61850 honeypot 

[name key vate —— 
| New connection ip | Ipof connected client- 
| Connection closed — |ip | Ip of disconnected client — 
Control operation [ip [Ipofclientsending control operation | 


7 Capec classification homepage, https://capec.mitre.org/ 
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ctINum ctINum attribute send by the client 
orCat Originator category provided by the client 


Logical Node 

Requested Control object 

SELECT | OPERATE 

Interlock-check requested by client 

Ip of client sending control operation 

Logical node owning requested data object 
Data object owning requested data attribute 
Requested data attribute 

Ip of client sending control operation 

Ln Logical node owning requested data object 
dataObject Data object owning requested data attribute 


dataAttribute Requested data attribute 


dataObject 
command 
interlockCheck 


Read Operation 
Ln 
dataObject 
dataAttribute 


Write Operation 


Finally, an example of an event is presented: 


("eventld":"0001", "name": New  connection","timestamp":"Tue Mar 19 22:04:00 4448757", 
"parameters" :("ip":"XX.XX.XX.13","param2":"Another param"}} 


e  |EC60870-5-104 
The format of the log for this honeypot is (Table 12): 


e timestamp: Timestamp with the exact time in which the event occurred. The format 
of the timestamp is yyyy-MM-dd'T'HH:mm:ss*SSSZ 

e sensorid: Sensor identification 

e id: Event identification 

e src ip: Source IP address 

e src port: Source TCP/UDP port 

e dst ip: Destination IP address 

e dst port: Destination TCP/UDP port 

e data type: Protocol 

e request: The action sent to the honeypot 

e response: The response to the request done by Honeypot 

e event type: This field is a code that corresponds to the specific event types cover by 
this Honeypot. There is more event types but they are associated with the Conpot 
honeypot where this honeypot is based on 


Table 12. Types of events for the IEC60870-5-104 honeypot 

| Evet | Event type 
C CL NA 1 
C RD NA 1 
C CS NA 1 


Test command C TS NB 1 
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C RP.NC 1 
Delay acquisition command C CD NA 1 


Finally, an example of an event is presented: 


{"timestamp": "2020-06-22T16:44:34.656128", "sensorid": "default", "id": "245cc5ac-ba77- 
4677 -4276-876976583791", "src ip": "XX.XX.XX.55", "src port": 6XX39, "dst ip": 
"XX.XX.XX.135", "dst port": 2XX4, "data type": "iec104", "request": null, "response": null, 
"event type": "C RD NA 1") 


e Modbus 


The structure of this Modbus honeypot is the same as the one described for the IEC60870-5-104, due 
to the fact that both are based on the Conpot honeypot, and extended its functionalities. The extended 
functionalities in this modbus honeypot are: 


e Mask Write Register(FC22 (0x16)): It changes the content of a holding register based on the 
use of AND and/or OR logical masks and the holding register's current content. 

e Read/Write Multiple registers 8FC23 (0x17)): It operates as both read and write operations in 
a single Modbus command. The write process preceded the read process. 

e Read FIFO Queue FC24 (0x18): It reads the content of a register's First-In-First-Out (FIFO) 
queue 


An example of an event is presented: 


{"timestamp": "2019-11-25T13:34:53.902098", "sensorid": "default", "id": "167b36dc-af68- 
4935-8393-490972134866", "src ip": "XX.XX.XX.80", "src port": 6XXX4, "dst ip": 
"XX.XX.XX.106", "dst port": 5XXX0, "public ip": "XX.XX.XX.106", "data type": "modbus", 
"request": null, "response": null, "event type": "NEW CONNECTION") 


4.2.2 Network based incident detection: Enhanced Suricata 
According to the Suricata documentation*: 


“Suricata is a high performance Network IDS, IPS and Network Security Monitoring engine.” 


Therefore, Suricata can work both as IDS and IPS. Both modes are based on rules that produces verdicts 
related to alerts or logs when working as IDS, adding drop, sdrop and reject actions when working as 
IPS. Suricata sniffs traffic directly from the network interface that is specified in the configuration, 
allowing to filter traffic related to a specific IP domain. The process that Suricata follows to process 
network traffic comprises three steps: (1) packet capture, which is the process that sniffs the network 
traffic from the specified interface, (2) decodes the stream, which is the process that parse the traffic 
and interpret its content, (3) detection, which, based on the information extracted from the traffic 
captured, applies the predefined rules and generates logs for those alerts that are triggered, and (4) 


8 https://suricata.readthedocs.io/en/suricata-5.0.3/what-is-suricata.html 
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output, which generates the corresponding log. The set of rules to use during an execution of Suricata 
is also configurable. 


Suricata already includes with a wide variety of rules capable of detecting a myriad of incidents, from 
denial of service attacks, to port scanning, suspicious activities, etc. Within SDN-microSENSE additional 
rules have been created, which allows to detect incidents associated to some of the EPES specific 
protocols, such as DNP3, IEC 60870-5-104, IEC61850 and Modbus. The following rule is an example 
that alerts about a potential denial of service over the IEC60870-5-104 protocol: 


alert tcp $EXTERNAL NET 2404 -» $HOME NET any (msg:"PROTOCOL-SCADA IEC 104 force on 
denial of service attempt"; flow:to client,established,no stream, content:"|68|"; 
depth:1; content:"|2D|"; within:1; distance:5; content:"|@1|"; within:1; distance:8; 
detection filter:track by src,count 50,seconds 5; 
reference:url,dragos.com/blog/crashoverride/CrashOverride-01.pdf; reference:url,us- 
cert.gov/ncas/alerts/TA17-163A; reference:url,welivesecurity.com/wp- 
content/uploads/2017/06/Win32 Industroyer.pdf; classtype:attempted-dos; sid:43228; 
rev:4;) 


Suricata logs are integrated in the XL-SIEM natively, although new rules added requires to be 
incorporated to the XL-SIEM data source catalogue. To this end, as it was described in Section 5, the 
plugin id that identifies Suricata sensors at the XL-SIEM is 1001, while the plugin sid used to identify 
the type of event received from Suricata sensors depends on the rule triggered. In this case, Suricata 
already identifies rules with a unique numerical identifier, called sid, which is used by the XL-SIEM 
Agent to map to the plugin sid variable used to identify the event type at the XL-SIEM side. 


Further details about the enhancement carried out in Suricata to incorporate detection capabilities 
within EPES infrastructures are given in D5.2. 


4.2.83 SDN based incident detection: Nightwatch 
Nightwatch is an Intrusion Detection and Classification Module (IDCM) for advanced and novel threats 
to Electrical Power Energy Systems (EPES). It leverages artificial intelligence technologies for accurately 


and rapidly determining X the likelihood that such a system has been 
compromised. Nightwatch supports low-computational analysis and machine learning techniques 
for resource constrained devices common in EPES environments. In “the SDN- 


microSENSE, Nightwatch is using information derived from the SDN-controller to determine whether 
the SDN components are under cyber-attack. Additionally, Nightwatch can determine the type of the 
attack and likelihood that an SDN component has been compromised. 

The communication between Nightwatch and the SDN-controller is made through the SDN- 
controller's Northbound interfaces. Nightwatch will gather  network-related information using 
Representational State Transfer (REST) based queries. The network information will include the 
network topology of the SDN switches, available network ports, and statistical information related to 
the available network ports. The network-based information will enable Nightwatch to elicit the 
nature of threats targeting SDN components, such as malware, service, or resource disruption. 
Nightwatch will be able to consume data from XL-SIEM using the XL-SIEM's RabbitMQ message 
broker. Nightwatch will use the RabbitMQ to read events from XL-SIEM agents as inputs for its 
intrusion detection analysis. Security-related events from XL-SIEM will enable Nightwatch to augment 
its intrusion detection process with additional information on the security posture of the system. 
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The resulting analysis of Nightwatch based on input from the SDN-controller and the XL-SIEM agents 
will be made available to the XL-SIEM for a consolidated analysis of the security of the EPES system. 
Thetechnical specifications and use of Nightwatch with the SDN-controller and the XL-SIEM are further 
described in D5.2, as part of the SS-IDPS System. 


4.2.4 Modbus Intrusion Detection Sensor 

The Modbus Intrusion Detection Sensor is an ML-based Network Intrusion Detection System (IDS), 
which is capable of detecting 14 Modbus/TCP related cyberattack types. In particular, the sensor relies 
on Transmission Control Protocol/Internet Protocol (TCP/IP) network flow statistics and consists of the 
five following modules: a) Data Collection Module, b) Feature Selection and Pre-processing Module, c) 
Training Module, d) Detection Module and e) Response Module. The Data Collection Module is 
responsible for capturing the Modbus/TCP network traffic, using tcpdump. Following this, the Feature 
Selection and Pre-processing Module undertakes to extract and pre-process the Modbus network 
Statistics that will be used for the detection process. The Training Module constitutes an offline 
functional unit which is responsible for the training process of the ML models. Next, the Detection 
Module loads the binary ML model and thus performs the classification process. Finally, based on the 
outcome of the Detection Module, the Response Module stores the information of the corresponding 
malicious Modbus/TCP network flow in a log file, with a specific label which indicates the Modbus/TCP 
cyberattack. The Modbus Intrusion Detection Sensor can detect 14 Modbus/TCP related cyberattacks, 
including: 


1) modbus/function/readInputRegister (DoS), 
2) modbus/function/writeSingleCoils, 

3) modbus/scanner/getfunc, 

4) modbus/dos/writeSingleRegister, 

5) modbus/function/readDiscretelnputs (DoS), 
6) modbus/function/readHoldingRegister (DoS), 
7) modbus/function/readCoils (DoS), 

8) modbus/function/readInputRegister, 

9) modbus/function/writeSingleRegister, 

10) modbus/dos/writeSingleCoils, 

11) modbus/function/readDiscretelnput, 

12) modbus/scanner/uid, 

13) modbus/function/readCoils and 

14) modbus/function/readHoldingRegister. 


More details about the Modbus Intrusion Detection Sensor will be provided in D5.3. 


4.2.5 DNP3 Intrusion Detection Sensor 

The DNP3 Intrusion Detection Sensor is also an ML-based IDS which can recognise timely and with high 
accuracy DNP3-related cyberattacks. The architecture of the DNP3 Intrusion Detection Sensor is 
composed of six modules: a) DNP3 Traffic Sniffing Module, b) DNP3 Network Flow Statistics Extraction 
Module, c) Pre-processing Module, d) Training Module, e) Detection Module and f) Notification 
Module. The first module captures the DNP3 packets, storing them into pcap files. Next, the DNP3 
Network Flow Statistics Extraction Module receives the pcap and exports DNP3 flow statistics related 
explicitly to the DNP3 packets with including information from the previous communication layers (i.e., 
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transport layer, network layer, link layer, etc.). Then, the Pre-processing Module undertakes to 
normalise appropriately the DNP3 flow statistics. Thus, based on this information, the Training Module 
trains the ML model of the Detection Module, which in turn detects the DNP3-related cyberattacks. 
Finally, the Response Module stores in a log file the malicious DNP3 flows with a label which specifies 
the DNP3 cyberattack type. The DNP3 Intrusion Detection Sensor can recognise the following DNP3 
cyberattacks: a) DNP3 Disable Unsolicited Messages Attack, b) DNP3 Cold Restart Message Attack and 
c) DNP3 Warm Restart Message Attack. More information about the DNP3 Intrusion Detection Sensor 
will be provided in D5.3. 


4.2.6 IEC 60870-5-104 Intrusion Detection Sensor 

The IEC 60870-5-104 Intrusion Detection Sensor focuses on cyberattacks against IEC-104. It uses an 
appropriate trained an ML model, which receives as input IEC-104 flow statistics. In particular, IEC 
60870-5-104 Intrusion Detection Sensor is composed of six modules: a) Data Capturing Module, b) IEC 
60870-5-104 Flow Generator, c) Feature Selection and Pre-processing Module, d) Training Module, e) 
Detection Module and f) Notification Module. The first module is responsible for monitoring 
and capturing the IEC-104 network packets, using tcpdump. Next, IEC 60870-5-104 Flow Generator 
receives the output, i.e., the pcap file of the previous module and generates IEC-104 flow statistics that 
are related only to the header and the payload of the IEC-104 packets, without including information 
from the previous TCP/IP layers. Next, the Feature Selection and Pre-processing Module isolates and 
pre-processes appropriately only those elements that will be given to the ML model, which is trained 
by the Training Module. The Detection Module incorporates the ML Model, thus recognising IEC-104 
cyberattacks. Finally, the Notification Module updates a log file with the malicious IEC-104 flows, 
comprising a label denoting the IEC-104 cyberattack. D5.3 will detail the IEC 60870-5-104 Intrusion 
Detection Sensor. 


4.2. IEC 61850 (GOOSE) Intrusion Detection Sensor 

The IEC 61850 (GOOSE) Intrusion Detection Sensor is an ML-based IDS, discovering potential intrusions 
related to the GOOSE communication model. As in the previous cases, it consists of six modules: a) 
Data Collection Module, b) GOOSE Flow Generator, c) Feature Selection and Pre-processing Module, 
d) Training Module, e) Detection Module and f) Response Module. The first module is responsible for 
sniffing GOOSE packets and storing them into two files: a) pcap and b) JSON. Both files (i.e., pcap and 
JSON) are processed by the GOOSE Flow Generator, which produces GOOSE flow statistics. The Feature 
Selection and Pre-processing Module chooses and normalises the features that will be used for the 
training of the ML model and the training procedure is implemented offline by the Training Module. 
Following this, the trained ML model is integrated into the Detection Module, which composes the 
core of the IEC 61850 (GOOSE) Intrusion Detection Sensor, responsible for recognising the various 
GOOSE cyberattacks. As it was mentioned above, the Detection Module can discriminate four GOOSE- 
related cyberattacks: a) Data Manipulation, b) DoS, c) Message Suppression and d) Disturbance. Finally, 
the Response Module updates a log file with the abnormal GOOSE flows, including a label that signifies 
the corresponding GOOSE cyberattack. 


4.2.8 L-ADS 

The L-ADS (Live Anomaly Detection System) is a tool developed by Atos which use machine learning 
based models to detect anomalies in network flows. More specifically, the L-ADS can monitor traffic 
network directly from the network or read traffic captures to analyse its content. The L-ADS infer 
anomalous connections to and from devices connected to the infrastructure monitored. The captured 
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or read traffic is pre-processed and transformed into Netflow, which takes from the packets analysed 
just relevant information such as source and destination IPs, duration of the flow analysed or the size 
of the flow in bytes or packets, among others. 


The L-ADS [Granadillo+19] works in two modes: supervised and unsupervised. The former can work 
based on predefined rules that helps to identify anomalous connections, while the latter self-learn and 
infer in an autonomous way the anomalous connections. 


The L-ADS can detect anomalies associated to any protocol working on top of TCP or UDP. In SDN- 
microSENSE, the L-ADS has been enhanced with support protocols often used in the EPES domain. 
More details about the L-ADS in SDN-microSENSE are given in 5.3. 


4.2.9 CERTH ML detector 

The Machine Learning (ML) detector is the tool that identifies abnormal events in the network traffic 
and provides the corresponding information to the XL-SIEM. The purpose of the ML detector is to 
expand the capabilities of the L-ADS tool taking into consideration the Modbus, the MQTT and the NTP 
protocols. The architecture of the ML detector is depicted in the Figure 19 and composed of three main 
parts. In the first part the network traffic from the Modbus, the MQTT and the NTP protocol is being 
capture for both normal and abnormal events. The T-shark network protocol analyser? is used to 
capture packet data from the network and to produce the corresponding pcap files. Then in the second 
part for the data collection procedure, the CicFlowmeter”” is used to extract the features of the 
bidirectional netflows from pcap files and produces the csv files with the records of the features. The 
third part of the procedure concerns the development of the different ML models per protocol. Based 
on the methodology that have been proposed for the detection of cyber-attacks O, O, O the ML detector 
will be used for the detection of the attacks that associated with the Modbus, MQTT and NTP 
protocols. The log files with the predictions of each model will be sent to the XL-SIEM. The 
development of the different ML models focuses on the development of Artificial Neural Network 
(ANN) models that take into consideration the advantages and the disadvantages of the comparison 
from different machine learning techniques on SCADA systems. Yasakethu et. Al., O described the 
comparison of different machine learning techniques for the protection of SCADA systems. The results 
of the comparison in terms of the ANN prove that the usage of this classifier requires prior knowledge 
of the anomaly type, needs adequate balanced training data and demands large number of attack 
training data. There are two main advantages for the ANN models are: they constitute nonlinear data 
analysis and demand low computational time. The usage of the ANN aims to improve the challenges 
of big data that associated with difficulties to store, track, analyse, capture, and share the generated 
data O. Moreover, the extension of the ML detectors that have been developed for the multiclass 
classification, O, O, O in terms of self-training procedure and using data from the corresponding Use 
cases that will developed for the SDN-microSENSE project aims to expand the effectiveness of the ML 
detector for the Smart Grids. The validation of the proposed models will be obtained from the 
calculation of metrics such as the accuracy, the precision and the recall for each model. The detailed 
information for the ML detector and its components will be provided in D5.3 


? https://www.wireshark.org/docs/man-pages/tshark.html 
10 https://github.com/CanadianInstituteForCybersecurity/CICFlowMeter 
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Figure 19. The architecture of the CERTH ML detector 


The ML detector will provide the logs to the XL -SIEM tool in Json files. The information that will be 
provided is the following properties for each event: the Source IP, the Source Port, the Destination IP, 
the Destination Port, the Timestamp, the protocol and the Label that describes the type of attack. The 
Json schema that describes the information sent by the ML detector to the XL-SIEM is the following: 


| 


"type": "array", 
"items": [ 


( "type": "object", 
"properties": { 


"Flow ID": { 

"type": "string"}, 
"Src IP": { 

"type": "string"}, 
"Src Port": { 

"type": "integer"), 
"Dst IP": ( 

"type": "string"}, 
"Dst Port": { 

"type": "integer"), 
"Protocol": { 


"type": "integer", 
"Timestamp": ( 


"type": "string"), 
"Label": { 


"type": "string"}}, 
"required": [ 
"Flow ID", 
"Src IP", 
"Src Port", 
"Dst IP", 
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"Dst Port", 
"Protocol", 
"Timestamp", 
"Label" 

13] 


4.3 Interfaces and data exchanged 

Several mechanisms have been implemented in SDN-microSENSE for the interaction of the XL-SIEM 
with other components of the platform. The following subsections describe the mechanisms 
configured in SDN-microSENSE. 


4.3.1 XL-SIEM input mechanisms 

As depicted in Figure 6, the XL-SIEM receives logs, events and other input data from components, such 
as detectors or honeypots, through the XL-SIEM agent. The XL-SIEM agent receives raw logs, in 
different format (i.e., json or plan text) containing different type of information, which are normalized 
by the XL-SIEM Agent in a common, normalized format. Further details will be given in Section O. 
These logs are received by the XL-SIEM Agent using rsyslog. Rsyslog is an open source utility to send 
registry messages using an IP network. It natively included in any Unix based distribution so no 
additional software is required to use it. Although there are several alternatives to send information 
using rsyslog, one of the most common is the one depicted in Figure 20. In this configuration detectors 
(or any tool that will send logs to the XL-SIEM Agent), produces logs that are written in a log file. The 
rsyslog process detect new input to the log file and automatically forward it to the rsyslog server 
configured. This is a very flexible approach because minimum configuration is required at the detector 
(assuming that most of them already write their output to a file) and the rsyslog guarantees a 
transparent and efficient mechanisms to transfer information which can also be secured by using TLS 
certificated to secure the communication channel. 


Detector 


XL-SIEM 
tool 


Agent 


à Log file LM Log file 
~ «— — — mai q 


Rsyslog 
client 


Rsyslog 
server 


TLS secured channel | 


Figure 20. Exchange of information from detectors to the XL-SIEM agent using rsyslog 


The following steps were used to create a secure communication channel with the XL-SIEM agent using 
rsyslog. The only requirement for a tool that wants to communicate to the XL-SIEM agent using rsyslog 
as described in this document is that logs are written in a log file (i.e., mytool.log). Rsyslog will monitor 
that file and will forward the new logs included in such file to the Atos XL-SIEM agent 
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Step 1: Install Rsyslog-gnutls 
By default, Linux machines will have rsyslog available. To use it over a secure channel it is required to 
install the TLS support. For Debian/Ubuntu this is: 


[root@mymachine ~]# apt-get install rsyslog-gnutls 


Step 2: Copy the Atos certificate to any folder of your machine 
A certificate is required to use this secure channel. A new certificate (atos.cert.pem) was created for 
this purpose: 


[root@mymachine ~]# mkdir /etc/rsyslog-keys 
[root@mymachine ~]# cp atos-cert.pem /etc/rsyslog-keys/ 


Step3: Create a configuration file for the secure channel in rsyslog. 


At /etc/rsyslog.d create a new file (30-xlsiem.conf). It can be chosen any name as long as it 
ends with .conf. This content has to be added such file: 


$ModLoad imfile 

$InputFileName /var/log/mytool.log <= file which content will be sent to the server 

$InputFileTag mytool <= a tag that identifies the program that fills such file 

$InputFileStateFile mytool.log «- name of the log file 

$InputFileSeverity alert 

$InputFileFacility local6 

$1nputRunFileMonitor 

$InputFilePollInterval 1 

# certificate files 

$DefaultNetStreamDriverCAFile /etc/rsyslog-keys/atos-cert.pem «- path where the Atos 
certificate is 

# make gtls driver the default 

$DefaultNetStreamDriver gtls 

$ActionSendStreamDriverMode 1 # run driver in TLS-only mode 

$ActionSendStreamDriverAuthMode anon 


it forward just content of the file associated to such tag to the Atos rsyslog server 
if $programname == 'mytool' then @@(0)XX.XX.XX.XX:AAAA 
if $programname -- 'mytool' then stop 


Step 4: Restart rsyslog service 

[root@mymachine ~]# service rsyslog restart 
Or 

[root@mymachine ~]# systemctl restart rsyslog 
Step 5: Check status of the rsyslog service 
[root@mymachine ~]# systemctl status rsyslog 


An output without errors should be something like what shown in Figure 21. 
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Any error will be prompted. 


Step 6: Test 
The setup can be tested just by adding manually new content to the log file: 


[root@mymachine ~]# echo "This is a test from file" >> /var/log/mytool.log 


If everything is correct the Atos agent must have received the message including "This is a test from 
file" (Figure 22) 


root@21b344a7 :/etc/rsyslog.d# aa /var/log/syslog 


Apr 27 08:19:15 sdnclient testlog This is from file 
Figure 22. Proof that the message was received by the client 


4.3.2 XL-SIEM output mechanisms 

The main output of the XL-SIEM is basically alerts derived from the reasoning carried out by the XL- 
SIEM engine based on the events received from XL-SIEM agents. To this end, several mechanisms are 
included in the XL-SIEM engine to export these security alert: to a csv file, to a Kafka broker, etc. The 
mechanism used in SDN-microSENSE to export security alerts is based on a RabbitMQ server. 


On the other hand, XL-SIEM agents send normalized events to the XL-SIEM engine by using a secure 
TCP socket connection. However, the XL-SIEM provides with an optional mechanism to export these 
events to third parties through a RabbitMQ server. Using a RabbitMQ broker provides with advantages 
when integrating other components of the SDN-microSENSE platform: 


e Events and alerts are exported in real time. 

e Security is guaranteed by using TLS secured channels to communicate with the RabbitMQ 
server. 

e Flexibility to attach any number of consumers just by attaching them to the corresponding 
queue for events or alerts. 


Within SDN-microSENSE, the capability to export events and alerts to a RabbitMQ is used by several 
components, as depicted in Figure 23. 
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Figure 23. SDN-microSENSE components using the output of the XL-SIEM Agent and Engine through RabbitMQ 


e Events exported from the XL-SIEM agent is used by the Nightwatch tool (further described in 
D3.3 and D5.2). As part of T3.3, Nightwatch uses these events for detecting zero days attacks 
based on the output from honeypots. Nightwatch also uses these events, along with SDN 
controller logs, to detect incidents as part of the SDN-IDPS developed in T5.2. 

e Events exported from the XL-SIEM agent to the Discóvery system, used to visualize 
infrastructure topology based on the information retrieved from detectors (further described 
in D5.3) 

e Alerts exported from the XL-SIEM engine that is used by several components of the SDN- 
microSENSE architecture: 

o Bythe ATOS CIS, which is used to interface with the ARIEC component developed in 
T5.5 (described in D5.5). 

o Bythe Honeypot Manager, part of T3.3 and described in D3.3, which uses them to 
identity zero days attacks and dynamically deploy additional honeypots in case it is 
necessary and according to the type of zero-day vulnerability exploited. 


The configuration used for setting-up the RabbitMQ queues is of type Fan-out, which leverages on 
exchange queues where the XL-SIEM Agent and Engine push events and alerts while consumers will 
create their own consumer queues, attach them to the corresponding exchange queue and read from 
it. This is the best possible solution when more than one consumer is expected. Otherwise, if all 
consumers read from the same consumer queue, some data will arrive to some consumers while other 
consumers will miss some data such as messages pushed to consumer queues are removed when 
consumed. 


The make integration easier a python script has been created to read from the RabbitMQ server set 
up for the XL-SIEM. The following is the configuration file used for the python connector created when 
connected to the alarms exchange queues: 
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[SERVER] 
SERVER IP - «IP of the RabbitMQ server» 
SSL PORT - «Port of the RabbitMQ server» 


[CLIENT] 
CONSUMER NAME - «component name» 


[QUEUES] 
EXCHANGE QUEUE NAME 
CONSUMER QUEUE. NAME 


atos.exchange.alarms.sdnmsense 
atos.queue.alarms.sdnmsense 


[CERTIFICATES] 

CA CERT = ./cacert.pem 
CLIENT CERT = ./cert.pem 
CLIENT KEY = ./key.pem 


The key parts of the configuration are the EXCHANGE QUEUE NAME, the CONSUMER QUEUE NAME 
and the CONSUMER NAME. The EXCHANGE QUEUE NAME must match the exchange queue 
configured at the RabbitMQ server, while the CONSUMER QUEUE NAME is used to create the 
consumer queue at the RabbitMQ server that is bound to the EXCHANGE QUEUE NAME. The 
CONSUMER NAME is also used to create the name of the consumer queue, added as suffix to the 
CONSUMER QUEUE NAME, meaning that the consumer name will be configured as 
“CONSUMER QUEUE NAME.CONSUMER NAME”. This is done to better identify at the RabbitMQ 
server the queues created by components. 


Figure 24 shows the RabbitMQ control panel with the exchange queues created by the XL-SIEM Agent 
and Engine. 


. Refreshed 2020-07-08 14:31:55 | Refresh every 5 seconds ~| 

ka R a bb It 3.7.14 Erlang 21.3.8.1 Virtual host | All v | 
Cluster rabbit@xIsiem-rabbitmq 

Overview Connections Channels User admin 


KA..-- M 


All exchanges (10, filtered down to 2) 


Pagination 

Page | 1 ~| of 1 - Filter: san C Regex ? Displaying 2 items , page size up to: 100 
Name Type Features Message rate in Message rate out +/- 
atos.exchange.alarms.sdnmsense 5 fanout (D) 0.00/s 0.00/s 
atos.exchange.events.sdnmsense  fíanout D 0.00/s 0.00/s 


Add a new exchange 


HTTP API Server Docs Tutorials Community Support Community Slack Commercial Support Plugins 


GitHub Changelog 
Figure 24. Exchange queues at the RabbitMQ attached to the XL-SIEM 


Figure 25 shows the RabbitMQ panel with the consumer queues attached to any of the exchange 
queues available. It is worth noticing that the python script provided as generic consumer deletes the 
consumer queue at exit. This is a normal behaviour and indeed desirable in order to save resources at 
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the RabbitMQ server. If the queue is created again later the exchange queue will push pending 
messages to the consumer queue just created, therefore guaranteeing that no messages are lost. 


: a Refreshed 2020-07-08 15:52:01 | Do not refresh v| 
lihRabbitM Q 3.7.14 Erlang 21.3.8.1 


Virtual host | All “| 


Cluster rabbit@xIsiem-rabbitmq 


Overview Connections Channels Exchanges | Queues | Admin User admin (ETS 


Queues 
v All queues (4) 


Pagination 

Page | 1 v| of 1 -Filter: O Regex ? Displaying 4 items , page size up to: 100 
Overview Messages Message rates +/- 

Name Features State Ready Unacked Total incoming deliver / get ack 
atos.queue.alarms.sdnmsense (5) idle 1,056 0 1,056 0.00/s 

atos.queue.alarms.sdnmsense.cis D idle 595 0 595 0.00/s 
atos.queue.events.sdnmsense.nightwatch D idle 725 0 725 0.00/s 

wiser-agent-ATOS-dcb3 Exel idle 0 0 0 


^ Add a new queue 


HTTP API Server Docs Tutorials Community Support Community Slack Commercial Support Plugins GitHub Changelog 


Figure 25. Consumer queues configured at the RabbitMQ server 
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5 Event connectors 


This section will describe the procedure used by the XL-SIEM agent to normalize events, the format of 
the normalized event and the approach used in SDN-microSENSE to gather information from detectors 
and honeypots. 


The XL-SIEM agent receives logs through a rsyslog server. These logs, generated by detectors, can 
contain any information and can be specified in any format, such as json or plain text. The XL-SIEM 
agent receives those logs, filters them (for example, according to the type of log) and extracts the 
relevant information from them in order to generate a normalized event in a common format. 


The XL-SIEM agent is based on plugins which are created to process the logs received from the 
detectors. In general, every detector has a dedicated plugin capable of processing all types of events 
that such detector produces. These plugins process logs by using regular expressions, extracting 
information from logs and matching them to a set of predefined fields included in the normalized event 
exported to the XL-SIEM engine. 


Plugins are composed of three important parts: 


- ID definition. Every plugin has a numerical ID that clearly identifies it. It is normally used to 
identify the detector that sent the logs processed by the plugin. This ID is also used by the XL- 
SIEM Engine to know the detector associated to the event received and apply the 
corresponding correlation rules to those events 

- Source of logs. Plugins read logs received by the XL-SIEM agent through syslog. As specified in 
Section 4.3.1, the rsyslog server at the XL-SIEM agent store logs received in a file. Rsyslog can 
filter then and store these logs in different files depending on some field appearing in the log 
(for example, the name of the sensor). Every plugin contains the route to the file that contains 
the logs to process, reading and processing every new entry that is written in such file 

- Parsing sections. A plugin section will be able to parse one type of logs. Every plugin will contain 
one or more parsing section. This is useful to group logs in plugins, because detectors will be 
able to send more than one type of log. Every section will contain two parts: 

o Regular expressions. This is the regular expression that will parse the log process by 
the plugin. A perfect matching is required to extract information from the logs. If there 
is no match, the regular expression of the next section is evaluated. If there is no 
matching expression in any section, the log is ignored. 

o Normalized fields. This is the mapping between the fields extracted from the logs at 
the regular expression and the normalized fields used by the XL-SIEM engine. The is a 
limited set of fields that can be normalized. The data format used for normalized 
events is based the OSSIM format”, but adding several changes to simplify its 
processing. The most important ones are source and destination fields for IP, port and 
MAC address. It is also included fields for usernames, filenames, and nine free fields 
that can be mapped to any information extracted from logs. It is important to notice 
that every plugin section will map a variable called plugin sid, which is a numerical 
value that identifies the type of event within a plugin. This is also used by the XL-SIEM 
to identify the type of event and apply the appropriate correlation rules. 


11 https://cybersecurity.att.com/documentation/usm-appliance/events/event-details-fields.htm 
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For every new plugin to be developed it is necessary to know exactly the type of events that will be 
parsed and the exact format. Therefore, it is necessary to compile from detectors this information. In 
SDN-microSENSE it has been created a template that makes the compilation of information from 
detectors easier (Table 13). 


Table 13. Template to compile log taxonomies from detectors 


Log name A name that identifies the log 
Log description | The text describing the log 
Important fields | The fields from the log that might be important for the XL-SIEM engine 


Field type The format of the field. This is, whether it is a string, a numerical value, etc 

Possible values If possible, the possible values that every field has (i.e., O to 10 for a numeral value) 

Field A description of the meaning of such field. This is useful to create correlation rules at the XL-SIEM 
description engine 

Example An example of the log that the XL-SIEM agent will receive from this detector 


According to the WP5 architecture depicted in Figure 3, the following detectors will be integrated with 
the XL-SIEM agent: 


-  |DPS detectors: Enhance Suricata and Data Injection detector. The details of this log taxonomy 
are given in D5.2 

- SDN IDPS: Nightwatch. The details of this log taxonomy are given in D5.2 

- Machine Learning based detectors: UOWM, SID and OINF Machine learning based detector, 
ATOS L-ADS and CERTH machine learning models. The details of this log taxonomy are given in 
D5.3 

- Access control and data request detector. The details of this log taxonomy are given in D5.3 

-  Honeypots. This logs taxonomy is detailed in WP3. 
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6 Security alerts 


Security alerts are created by the XL-SIEM engine by correlating events received from detectors 
through the XL-SIEM agent. This correlation is done through a set of correlation rules that evaluate 
several aspects of associated to the events received from the XI-SIEM agent. This evaluation uses the 
fields included in the event (for example, to compare source IPs) and include additional variables to 
compare such as the number of occurrences of certain types of events, a time window where to receive 
events, etc. 


For every new event received from SDN-microSENSE detectors, it is required to evaluate its content, 
and determine whether it can be inferred an incident, and therefore, to trigger the corresponding alert. 


Therefore, new rules have been created to deal and evaluate the events received from SDN- 
microSENSE detectors. The process to create additional rules comprises several steps, as depicted in 
Figure 26. 


Set up new Classify Create 


Add directives 


to correlation 


event definitions events directives 


Figure 26. Steps to create new correlation rules 


Set up new event definitions 

For the XL-SIEM to process new events received from SDN-microSENSE detectors it is required to let 
the XL-SIEM engine know that new events are available. To do so, for every new detector (this is, for 
every new plugin developed at the XL-SIEM agent) it is required to configure a new Event type at the 
XL-SIEM. New event types are defined at the XL-SIEM by using the plugin id defined at the plugin and 
the plugin sid defined for every event type that a detector is sending. Figure 27 represents the 
configuration panel at the SDN-microSENSE XL-SIEM that shows two event types for the Dionaea plugin 
(plugin id21669). The Data Source ID field corresponds to the plugin id of the event while the Event 
Type ID corresponds to the plugin sid of the event. Additionally, the fields category, subcategory, 
priority and reliability can be fixed. It is worth noticing that the values priority and reliability will be 
used to determine the severity (shown as risk) of incidents associated to these events. 
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> Dashboards > SIEM Analysis > Configuration > Reports 
Event types (1669, dionaea) <<Back to Data Source Displaying 1 to 2 of 2 event types 
i Insert new eventtype jEdit | Delete selected 
Data Source ID — ID Category Subcategory Class Name Priority Reliability 
| 1669 1 Honeypot Connection Opened - Dionaea: Incoming Connection 2w iv 
1669 2 Honeypot Attack_Detected - Dionaea: Malware detected Jv iv 


Figure 27. Example of event definition for one of the honeypots 


Classify events 

Once the XL-SIEM knows that new types of events will arrive it is required to classify the important 
ones. For important ones it is understood those that are relevant for the detection of potential 
incidents, which will be the ones to process when applying incident correlation rules. At the XL-SIEM 
this classification is done through EPL statements, which basically filter events given by a specific 
plugin_id and plugin_sid. Figure 28 shows the statement used to classify events with plugin_id=1001 
and plugin_sid=2009286 as events related to the detection of scans using the Modbus protocol. Events 
matching these two values are classified into Scada_Modbus_ scanning detected events. 


> Dashboards > SIEM Analysis > Configuration > Reports 


| Statement Name * Scada_Modbus_scanning_detected 


insert into Scada_Modbus_scanning_detected select 
“from ossimSchema default where (plugin id-1001) 
and (plugin sid-2009286) 


EPL 
A 


Update Clear Cancel 


Figure 28. Example of an event classification for Modbus related events 


Create directives 

Next step is the definition of the directive that represents the correlation rule to apply when events 
classified in the previous step arrive. Here is where the logic used to trigger security alerts is applied. 
The events classified in previous steps are used to apply rules that uses variables such as number of 
occurrences, events appearing within a certain period of time, or values contained in such event. The 
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syntax used to define these rules is EPL!?. Figure 29 represents an example of a correlation rule that 
triggers a security alert about a scanning against an IP. This alert is triggered when three events 
(classified as Scada Modbus Scanning detected) occurs within 100 seconds and against the same IP 
(a.dst ip). In addition, and similar to the definition of events, categories, subcategories, reliability and 
priority are defined for this alert. 


SDN-uSense 


b Dashboards 


> SIEM Analysis > Configuration > Reports 


EPL Directives EPL Statements EPL Variables Schemas Storm Topology Configuration 


Directive SID * | [27003 2 


directive event. SCADA attack, Modbus scanning or 
Name * fingerprinting against DST IP 


4 


pattern [ every-distinct(a.dst ip.100 seconds) 
a-Scada Modbus scanning detected -> ( 

b-Scada Modbus scanning detected((b.src ip-a.src 
EPL Pattern |. ip) and (b.dst ip-a.dst ip)) -> 

c-Scada Modbus scanning detected((c.src ip-a.src 
| ip) and (c.dst ip-a.dst ip)))] 


Category Alarm v] 
Subcategory Scada v] 
Reliability * 8 v 

Priority * 4 | 


Update Clear Cancel 


Figure 29. Example of directive (correlation rule) for a Modbus related incident 


Add directives to correlation 

Finally, the new correlation rules are added to the correlation engine (called Correlation Bolt in Storm 
terminology). Every correlation bolt contains the list of rules that are active, which depends on the 
domain or other requirements where the XL-SIEM is used. Figure 30 represents the panel where the 
new rule is added in the section “Directive”. 


1? https://docs.oracle.com/cd/E13157 01/wlevs/docs30/epl guide/overview.html 
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> Dashboards > SIEM Analysis > Configuration > Reports 


Correlation Bolts 


CorrBolt name * test 
Parallelism * [1 v] 
Data Schema * : 
Insert new Schema? | ne = | 
Description 
Scan Directives v| Add 


Scan Directives a 
Malware Directives 


Categories * DoS Directives 
BruteForce Directives 
Network Directives ad 
pg 
2 v| Add 
2 a 
Directives * 


Insert new Directive? 


ATOS - AVAPI filte: v | Add 
ATOS - AVAPI filter a 
Policies 
Insert new Policy? 


pa 


Figure 30. Configuration panel where new directives are added to the correlation engine 


This process for generating new correlation rules has been followed for every new detector and every 
new event received from SDN-microSENSE. The effort was required not just to create the new rules 
but to apply specific threat intelligence to explicitly know how to build the appropriate correlation rule. 
To this end it was required to understand the information contained in the events and the nature of 
the attacks detected, identifying patterns that need to be translated to rules and clearly identify alerts 
and avoid false positives. 


Security alert format 
The security alerts exported by the XL-SIEM uses a data format very similar to the format of the 
normalized events, also based on OSSIM and using json, but with several differences. 


Table 14 describes the list of fields included in a security alarm. Apart from the fields that are common 
to events, it is worth noticing the following aspects: 


- . BACKLOG ID: A unique ID used to identify the alert 
- EVENT ID : The XL-SIEM allows to use alerts as events and apply cross correlation rules using alerts as 
events. This field represents the ID associated to the alert when it acts as an event. 


@ SDN-microSENSE consortium Page | 56 
Public document 


e SDN-u Sense 
D5.1 


Version 1.5 


- | RELATED EVENTS: As it was mentioned before, security alerts are triggered by correlating events (one 
or more than one like in the example above). This field represents the IDs of the events that has been 
used to generate the alert. 

- | RELATED EVENTS INFO: This field contains an json array, every element containing the complete 
events used to correlate and generate the alert. 


Table 14. Fields of the security alert message exported by the XL-SIEM 


XL-SIEM Description 
DATE Date and time of the alert. 
SENSOR Agent that sent the events used to create the alert. 
PLUGIN SID ID assigned to identify the alert type. 
EVENT ID Unique ID number assigned to the alert by the XL-SIEM. Used to use alerts as 
= events and perform cross correlation rules 
PROTOCOL le used for the source/destination associated to the alert, for example, 
CATEGORY Event taxonomy for the alert, for example, Authentication or Exploit. 
ee (ee 
SID NAME Name of the external application or device that produced the alert. 
PLUGIN ID ID associated with the external application or device that produced the alert. 
PRIORITY Priority ranking, based on value of the alert. Each alert type has a priority value, 
used in risk calculation. 
RELIABILITY Maa n kaa of trust on the detector that has provided the events used to 
RISK Risk level of the event, being O the minimum and 10 the maximum 
SRC IP IP address for the source of the events associated to the alert 
DST IP IP address for the destination of the event associated to the alert 
SRC IP HOSTNAME Hostname of the event source. 
DST IP HOSTNAME Hostname of the event destination. 
SRC PORT External or internal asset source port for the event associated to the alert 
DST PORT External or internal asset destination port for the event associated to the alert 
FILENAME Only applicable to certain alerts. 
BACKLOG ID Internal ID used by the XL-SIEM to identify the alert 
USERNAME Only applicable to certain alerts. 
PASSWORD Only applicable to certain alerts 
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The organization where the incident has been discovered. Useful with 


ORGANIZATION multitenancy based deployments (one XL-SIEM instance, several organizations). 


USERDATA1-9 Custom data variable depending on the alert and the sensor. 
RELATED_EVENTS Event_id of the events that have triggered the alert. 
PLUGIN_NAME The name of the agent sending the event associated to the alert 


json with the complete information about events that triggered the alarm (one 


RELATED_EVENTS_INFO 
- = or more events) 


These alerts are stored at the XL-SIEM database and exported to the RabbitMQ defined in Section 
4.3.2, and consumed by several components of the SDN-microSENSE architecture as defined in Figure 
23. 
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/ Unit Testing 


7.1 Unit Testing Environment 

A testbed has been created to verify and validate the interconnection of the different detectors used 
in SDN-microSENSE with the XL-SIEM deployed at the XL-EPDS. This testbed has been deployed at ATOS 
premises and is publicity available for partners to test interconnection with XL-SIEM inputs and 
outputs. 


The testbed architecture is shown in the following figure: 


Hosting server 
VM1 VM2 VM3 
VPN Server XL-SIEM Agent XL-SIEM Engine 


GING 
ms 
GINB 


management 


Test detector 


Remote 


Event Alarm 
consumers consumers 


Detectors 


Figure 31. XL-SIEM testbed in SDN-microSENSE 


The testbed has been deployed in a hosting server at Atos premises. It has been mounted by using 
several virtual machines that corresponds to several components of the XL-SIEM interconnected 


through a NAT network. The details of these virtual machines are the following: 


VM1: It contains a VPN server, that is used for the remote management of the complete 
infrastructure. It also contains a testing client that allows to send test logs to the XL-SIEM 
agent. The Port A of the VM1 is forwarded to the Port HA of the hosting server, which allows 
to establish a VPN connection from the public internet using Port HA. 

VM2: It contains an instance of the XL-SIEM Agent. This agent contains the rsyslog server that 
listens in Port B for logs coming from detectors. To do this, the Port B at the VM2 is forwarded 
to the Port HB, which is publicly available for detectors to send logs. 

VM3: It contains an instance of the XL-SIEM Engine containers, which receives normalized 
events from the XL-SIEM Agent directly through the NAT network by using a secure TCP 
connection directly to the VM3. This VM3 also contains a dockerized instance of a RabbitMQ 
server that receives events from the XL-SIEM at VM2 through the NAT network and security 
alerts from the XL-SIEM Engine directly within the local loopback at VM3. Consumers of events 
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and alerts can connect to the RabbitMQ server through the Port HC of the hosting server, 
which is forwarding the Port C of the RabbitMQ server at VM3. 


Therefore, just ports HA, HB and HC of the hosting server are exposed to the public internet. The 
access to the rest of services available at the VMs of the testbed (such as SSH connections or access 
to web servers to manage dashboards) is just possible through the VPN server. 


It is worth noticing that these ports are just used at the testbed, not being used or exposed in any 
deployment on the real pilots. 


As shown in Figure 31, several detectors and consumers of events and alarms has been 
interconnected to the testbed for checking connectivity. These tests are part of the Unit Testing 
phase defined in T2.4 as part of the evaluation strategy depicted in Figure 32 


Verification and Validation 


Requirements Acceptance 
analysis testing 


System design 


Acceptance Test Design 


System Test Design System testing 


Integration 
testing 


Integration Test Design 


Project Project test 
definition and 
integration 


Implementation - Coding 


Time 
Figure 32. Evaluation strategy in SDN-microSENSE (extracted from T2.4) 


7.2 Unittests 
The following tests have been carried out. It is worth noticing that all IPs has been hidden. Ports 
appearing in the tests are fictitious and does not correspond to any active or available service. 


Test Case ID XL-EPDS-01 Component XL-SIEM Agent 
Description Basic connectivity between a test detector and the XL-SIEM Agent and 
normalization of the event 
SPEC ID SPEC-F1, SPEC-F2 Priority High 
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Prepared by ATOS Tested by ATOS 


Pre-condition(s) | A test detector and an XL-SIEM Agent needs to be deployed 


Test steps 


1 


At the test detector a log is simulated by adding a new testing log in the file monitored by the 
rsyslog client: 


echo '[testSensor] TEST EVENT: {src_ip=XX.XX.XX.11, port-111, dst ip-XX.XX.XX.99, dst port-397, 
desc-"This is an event"}' >> /var/log/test.log 


The rsyslog client automatically dispatch the log to the XL-SIEM agent, which is received and 
stored in /var/log/test logEvent.log 


root@ec0438170ba7:/var/log# tail -n 1 test logEvent.log 


Jul 22 14:27:58 sdnclient testlog [testSensor] TEST EVENT: (src ip-XX.XX.XX.11,  port-CC, 
dst ip-XX.XX.XX.99, dst port-BB, desc-" This is an event "} 


The log is normalized by the XL-SIEM agent: 


2020-07-22 14:27:50,733 Output [INFO]: 
("event":("type":"detector","date":"1595428070" , device": "XX.XX.XX.9", "interface":"eth0","plugin 
id":"30000","plugin sid":"1","src ip":"XX.XX.XX.11","src port":"BB","dst ip":"XX.XX.XX.99","dst p 
ort":"CC","userdata1":"VEVTVF9FVkVOVA--" , "userdata2" : "VGhpcyBpcyBhIGFzZHMgZWF2ZW50" , "log": "SnVsID 
IyIDE003130jUwIHNkbmNsaWVudCB0ZXNObG9nIFt0ZXNOU2Vuc29yXSBURVNUXOVWRU5UOiB7c3JjX21wPTEXLjEXLjExLjE 
XLCBwb3J0PTExMSwgZHNOX2 1wPTk5Ljk5Ljk5Ljk5LCBkc3RfcG9ydDOzOTcsIGRlc2M9IlRoaXMgaXMgYSBhc2RzIGVhdmVu 
dCJ9IA--","fdate":"2020-07-22 14:27:50", "event_id":"cc2711ea-936b-0242-ac11-000285b6525a"}} 


Input data Test log: 


[testSensor] TEST EVENT: {src_ip=XX.XX.XX.11,  port-BB, dst ip-XX.XX.XX.99, 
dst port-CC, desc-"This is an event") 


Result Log correctly normalized by the XL-SIEM Agent: 


2020-07-22 14:27:50,733 Output [INFO]: 
("event":("type":"detector","date":"1595428070" , device": "XX.XX.XX.9", "interface 
"i"ethe","plugin id":"30000","plugin sid":"1","src ip":"XX.XX.XX.11","src port": 
"BB","dst ip":"XX.XX.XX.99","dst port":"CC", "userdata1":"VEVTVF9FVkVOVA--" , "user 
data2" : "VGhpcyBpcyBhIGF zZHMgZWF 2ZW50" , "log": "SnVsIDIyIDE@0j 130jUwIHNkbmNsaWVudCB 
0ZXNebG9nIFt0ZXNOU2Vuc29yXSBURVNUXOVWRUSUOiB7c3J jX21wPTEXLj ExLjExLjExLCBwb3J0PTE 
xMSwgZHNOX21wPTk5Ljk5Ljk5Ljk5LCBkc3RfcG9ydDOzOTcsIGRlc2M9IlRoaXMgaXMgYSBhc2RzIGV 
hdmVudCJ9IA--","fdate":"2020-07-22 14:27:50","event id":"cc2711ea-936b-0242- 
acii-000285b6525a")] 


Test Case Result | Achieved 


Test Case ID XL-EPDS-02 Component Honeypots 
Description Communication between honeypots logs and XL-SIEM 
SPEC ID SPEC-F1, SPEC-F2 | Priority High 
Prepared by ATOS Tested by TECN 
Pre-condition(s) Honeypot and XL-SIEM Agent needs to be deployed 
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Test steps 


1 | Atesting honeypot sends an example log to the XL-SIEM Agent using rsyslog at port 5200 


2 | The log is transmitted through the rsyslog secured channel 


3 | The logs is received by the XL-SIEM Agent 


Input data Log from the testing honeypot 
honeypot ("eventID": "0004", "name": "Read operation", "timestamp": "Tue Jul 
21 09:38:22 


2020", "parameters":("("key":"ip", "value": "XX.XX.XX.19:55157"Y,("key":"In", 
"value": "LPHD1"},{"key":"dataObject", "value": "PhyHealth"),("key":"fc", "val 
ue":"ST")")) 


Result Data received by the XL-SIEM agent at /var/log/syslog 


Jul 21 09:38:30 digitalenergypi honeypot 
("eventID":"0001","name":"Connection closed","timestamp": "Tue Jul 21 
09:38:30 2020","parameters":{"{"key": "ip", "value": "XX.XX.XX.19:CC"}"}} 


Test Case Result Achieved 

Test Case ID XL-EPDS-03 Component Nightwatch 
Description Communication between Nightwatch logs and XL-SIEM 

SPEC ID SPEC-F1, SPEC-F2 Priority High 
Prepared by ATOS Tested by CLS 
Pre-condition(s) Testbed deployed 

Test steps 


1 Nightwatch sends an example log to the XL-SIEM Agent using rsyslog at port 5200 


2 | The log is transmitted through the rsyslog secured channel 


3 | The logs is received by the XL-SIEM Agent 


Input data Message sent by CLS with a simple plain text message 
Result Log received at the XL-SIEM Agent: 
Jun 26 12:17:46 preetika-VirtualBox mytool This is a test file from CLS. 
Test Case Result Achieved 
Test Case ID XL-EPDS-04 Component UOWM detectors 
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Description Communication between Modbus Intrusion Detection Sensor logs and XL- 
SIEM 
SPEC ID SPEC-F1, SPEC-F2 Priority High 
Prepared by ATOS Tested by UOWM 
Pre-condition(s) Testbed deployed 


Test steps 


1 Modbus Intrusion Detection Sensor sends an example log to the XL-SIEM Agent using rsyslog 
at port 5200 


2 | The log is transmitted through the rsyslog secured channel 


3 | The logs is received by the XL-SIEM Agent 


Input data Message sent by UOWM with a simple plain text message 


Result Log received at the XL-SIEM Agent: 
Jun 30 16:34:06 snf-7871 uowm test This is a test from file 


Test Case Result Achieved 

Test Case ID | XL-EPDS-04 Component XL-SIEM Engine 
Description | Simple generation of test alert 

SPEC ID SPEC-F3, SPEC-F4, SPEC-F5 Priority High 

Prepared ATOS Tested by ATOS 

by 

Pre- Log sent to the XL-SIEM agent. 

condition(s | Correlation rules prepared at the XL-SIEM Engine 

) 

Test steps 


1 | Test XL-EPDS-01 is carried out to send an event to the XL-SIEM agent 


2 Normalized event is sent to the XL-SIEM engine from the XL-SIEM Agent 


3 | Correlation rules are applied, and a security alert is triggered 


Input data | Test logs, as defined in XL-EPDS-01 


Result Security alert issued by the XL-SIEM agent. 
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Ú Test event detected for alarm v a 1 8 > = 8 TUHAN 
Open Event Risk 0 secs. 35 mins ago [| 


Pi Source M Destination IR Knowledge base 


N N :: Incident Response: Info 


= HN = 
Test Case | Achieved 
Result 
Test Case ID | XL-EPDS-05 Component XL-SIEM engine (RabbitMQ) 


Description | Test to check that consumers can read alerts properly from the RabbitMQ where the 
XL-SIEM exports alerts 


SPEC ID SPEC-F3 Priority High 
Prepared by | ATOS Tested by ATOS 
Pre- Test XL-EPDS-04 


condition(s) | RabbitMQ deployed and configured 


Test steps 


1 | Test XL-EPDS-04 is carried out to generate a simple alert 


2 | Check the RabbitMQ panel that the alert is correctly pushed into the alerts queue 


Input data Test log 


Result Alert available at the RabbitMQ queue 
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ka R a b b | t M Q 3.7.14 Erlang 21.3.8.1 
Overview Connections Channels Exchanges Admin 


Queue atos.queue.alarms.sdnmsense.atos 


* Overview 


Queued messages last hour ? 


1000 


Ready W 931 
500 Unacked O 
0 Total W 931 
16:20 16:30 16:40 16:50 17:00 17:10 
Message rates last hour ? 
0.0/s | 
pa Publish B 0.00/s e E 0.00/s 
0.0/s Deliver 
0.0/5 (manual | 0.00/s Redelivered | B 0.00/s 
0.0/s ack) 
16:50 17:00 Get 
Deliver (manual E 0.00/s 
(auto ack) . E 0.00/s ack) 
Get (auto 
ack) B 0.00/s 


Message 1 


theserver} Evidences of alert received by the RabbitMQ server from the XL-SIEM 


Exchange | atos.exchange.alarms.sdnryfsense 


Routing 

Key 
Redelivered e 
Properties delivery mode: 


headers/ 
content encoding: UTF-8 


content type: application/json 


("AlarmEvent":("DST IP HOSTNAME" : "00000000" , "RELATED EVENTS":"[a1c011ea80fb0242ac110002f4a50bc0]","DST !P”: "GP". 


Achieved 
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& Innovation Summary 


The main innovations derived from the work carried out in T5.1 are related to the support of protocols 
commonly used by EPES, such as Modbus, DNP3, IEC 60870-5-104, IEC61850 and IEEE C37.118. With 
the support of these protocols the XL-SIEM spans its usage to additional domains not possible before 
SDN-microSENSE, such as EPES and also other domains where those protocols are commonly used (i.e., 
Modbus, largely used in the industry domain). More specifically, adding support of these protocols has 
entailed several activities such as understanding the logs generated as a result of the activities carried 
out using them, processing them, parsing them and interpreting the information contained. 
Additionally, an effort of security intelligence has been required to 


1) identify patterns associated to the type of logs received, evaluating different criteria such as their 
occurrence, 
2) identify anomalies associated to those patterns, 
3) create correlation rules to automate the generation of security alerts upon the reception of logs 
matching those patterns identified as incidents 
4) export those alerts for their usage by other components of the SDN-microSENSE platform, namely 
to 
a. export anonymous threat intelligence by the ARIEC, 
evaluate impact and design self-healing actions through the S-RAF, and 
c. automatically deploy honeypots by the Honeypot Manager upon reception of zero-day 
attack alerts. 


As it has been highlighted before, this deliverable is the first document that reports outcomes of WP5 
tasks and many of the aspects described here will be extended in more detail in the following 
deliverables of WP5: 


e Detection of attacks associated to EPES protocols is described in D5.2 

e Machine learning based tools to detect attacks associated to EPES protocols are described 
in D5.3. 

e Detection and reporting of access control activities and privacy aspects are described in 
D5.4. 


Threat information sharing capabilities and anonymization are described in D5.5 as part of the 
development of the ARIEC component. 
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9 Conclusions 


This deliverable has presented the details of the XL-EPDS module, in charge of managing the detection 
of cyber incidents within EPES infrastructure. Within the XL-EPDS module, this deliverable describes 
the core of this module, represented by the XL-SIEM which bridges the detectors deployed in the EPES 
infrastructure monitoring different protocols commonly used by the EPES domain. 


This deliverable has also described the mechanisms developed to exporting security alerts and 
normalized events, which interface with several components of the SDN-microSENSE infrastructure. 
These mechanisms are based on messaging queues using RabbitMQ. 


This is the first document reporting activities carried out in WP5, including details of the protocols 
being monitored by the XL-EPDS and initial highlights of the detectors developed to monitor those 
protocols, which are connected to the XL-SIEM to send logs for its correlation, applying new correlation 
rules created specifically for the detection of incidents within EPES infrastructures. 


Finally, this document has also detailed the testbed deployed to test the initial connections of external 
components, not just WP5 components but also from other WPs, with the XL-SIEM. A set of unit tests 
has also been carried out and described in this deliverable. 
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